NASA/TM-2017-219670 


An Advanced Trajectory-Based Operations 
Prototype Tool and Focus Group Evaluation 


Nelson M. Guerreiro, Denise R. Jones, Bryan E. Barmore, Ricky W. Butler, George E. Hagen, 
Jeffrey M. Maddalon, Nash’at N. Ahmad, Laura J. Rogers, and Matthew C. Underwood 
Langley Research Center, Hampton, Virginia 


Sally C. Johnson 
Adaptive Aerospace Group, Inc., Hampton, Virginia 


September 2017 


NASA STI Program .. . in Profile 


Since its founding, NASA has been dedicated to the 
advancement of aeronautics and space science. The 
NASA scientific and technical information (STI) 
program plays a key part in helping NASA maintain 
this important role. 


The NASA STI program operates under the auspices 
of the Agency Chief Information Officer. It collects, 
organizes, provides for archiving, and disseminates 


NASA’s STI. The NASA STI program provides access 


to the NTRS Registered and its public interface, the 
NASA Technical Reports Server, thus providing one 
of the largest collections of aeronautical and space 


science STI in the world. Results are published in both 


non-NASA channels and by NASA in the NASA STI 
Report Series, which includes the following report 


types: 


e TECHNICAL PUBLICATION. Reports of 


completed research or a major significant phase of 


research that present the results of NASA 


Programs and include extensive data or theoretical 


analysis. Includes compilations of significant 
scientific and technical data and information 
deemed to be of continuing reference value. 
NASA counter-part of peer-reviewed formal 
professional papers but has less stringent 
limitations on manuscript length and extent of 
graphic presentations. 


e TECHNICAL MEMORANDUM. 
Scientific and technical findings that are 
preliminary or of specialized interest, 
e.g., quick release reports, working 
papers, and bibliographies that contain minimal 
annotation. Does not contain extensive analysis. 


e CONTRACTOR REPORT. Scientific and 
technical findings by NASA-sponsored 
contractors and grantees. 


e CONFERENCE PUBLICATION. 
Collected papers from scientific and technical 
conferences, symposia, seminars, or other 
meetings sponsored or co-sponsored by NASA. 


e SPECIAL PUBLICATION. Scientific, 
technical, or historical information from NASA 
programs, projects, and missions, often 
concerned with subjects having substantial 
public interest. 


e TECHNICAL TRANSLATION. 
English-language translations of foreign 
scientific and technical material pertinent to 
NASA’s mission. 


Specialized services also include organizing 
and publishing research results, distributing 
specialized research announcements and feeds, 
providing information desk and personal search 
support, and enabling data exchange services. 


For more information about the NASA STI program, 
see the following: 


e Access the NASA STI program home page at 
http://www.sti.nasa.gov 


e E-mail your question to help@sti.nasa.gov 


e Phone the NASA STI Information Desk at 
757-864-9658 


e §=©Write to: 
NASA STI Information Desk 
Mail Stop 148 
NASA Langley Research Center 
Hampton, VA 23681-2199 


NASA/TM-2017-219670 


An Advanced Trajectory-Based Operations 
Prototype Tool and Focus Group Evaluation 


Nelson M. Guerreiro, Denise R. Jones, Bryan E. Barmore, Ricky W. Butler, George E. Hagen, 
Jeffrey M. Maddalon, Nash’at N. Ahmad, Laura J. Rogers, and Matthew C. Underwood 
Langley Research Center, Hampton, Virginia 


Sally C. Johnson 
Adaptive Aerospace Group, Inc., Hampton, Virginia 


National Aeronautics and 
Space Administration 


Langley Research Center 
Hampton, Virginia 23681-2199 


September 2017 


The use of trademarks or names of manufacturers in this report is for accurate reporting and does not constitute an 
official endorsement, either expressed or implied, of such products or manufacturers by the National Aeronautics and 
Space Administration. 


Available from: 


NASA STI Program / Mail Stop 148 
NASA Langley Research Center 
Hampton, VA 23681-2199 
Fax: 757-864-6500 


Table of Contents 


Acronyms:anid SYMbols vs cccsscassccnesesccaushaecsegesiscodascdacecavtasceasteavcsedesnccegesiaccudechacessacuasessadavecedssvaccauecancsensaanvedsne iii 
Leo” VADStHA CE srcasedney tds loess tbuceistentbcveaiin te tbveieeeasbyeiattees capes teas loen eetanebusss leben catia sten a eeesste cere. 1 
2 J INTOMUCH OM sys c5 tees sleet vaceb sala taadevilocss detus dade uecshooldsGuedesvedandetah csadesni seb andes Teadootaass dobaesegel viedisuanesbsotiseceuess 1 
3 Advanced. 4D TT BO Concept y.dicicieccticesvectess oeste in ievacttin ecewiesaadedarwortin is atetde erste Tashi tiea ert bsd heen 2 
A “FBO Prototype sics. casess ovsiincsovesdvivens stuevsvosd vive setae seve autos ncvadecvossh dive ovttds soSeldvevseguatesveca¥iveoesteevnnttte sovedvads sede 4 
4.1 — Prototype Architecture and Capabilities 2.0.00... ce cecsecesesesceseesceeecesecseeeecesecsaeeaeeacesaecaeeeneaecseeenees 5 
4.2 Dynamic Area Navigation/Required Navigation Performance.............:cscscsesseeeceececeeeeeseceeeeneeaes 6 
4.3. ADS-C and Extended Projected Profile 0.0.0... ee ceessceseceseeseeeeeeecesecseeeecesecsaeeaeeeeeaecaeeeeeesecneeenees 7 
4.4 Advanced Interval Management .............:sccssccssscesecesecesecesecessesecesececeneeeseeensecssecseecsaecaeceaeceseeeseeeaes 7 
AS Required Time-of-Arrival os. .escccsscesccsseataccdsetaaccedessscedveasseduorsiecadesaacedaasencstnasanccddacabecataasacctalsvedeads 8 
4.6  User-Preferred Re-Route Request ........cccccssesssecssecsseceeceseseseceneeeneeeneecssecsaecsaeceseceseceseceeeeeseeeneeees 8 
4.7 ‘Time-Based Metering and Scheduling.............ccsesccssccessceseceseceseeeeceeseecseecsaecsaeceseceseceseceteeeeeeeeneeees 8 
4.8 COMMUNICATIONS es cs eccss deccetuss se vecwstecuvtsas so naveactcoutees es uacbaueeeducossustesvecedubecdcuscsseatends couddetess deveveveceenss 8 

D COVSLELD DES CTIPUOM si. tecescerestsbcadsdovececevsen deduesdadacevtaicad sd evbegdsesan deutbenncacuveabeads bagacd cay ean deudben ica duvbsbceesean calves 9 
B-b  STBOtAutomation TOONS esssscsss ste tscssssbenteseetecnaai sesh ieerotenastvseten vets taet ie sieeetenae Giant 9 
5.1.1 Plight Manager. iesi.ccass.ecgdesiavssisae dvd suse sted sasheo¥- ceestivesacson¥siees shor seh guide in esd¥oysheae odense Sinasbbecdeedt 10 
5.1.2 ATC AUtOMAT ON: :.ccievin cas eeescvestestessteedeevencdussbsbrerecveuecessdbevia dendecensdh sve paudeaueediesesestetenyeites 11 
5.1.3 Traffic Flow Management Automation .......... cc cescssescesecseeeeeesecsecseeencesecsaeeaeeeeaecaeeeneeaes 14 

5.2 Airborne: AUtOMAON v5.25 cineessadedynescteie scevses doseicecssoneceliosedubeoscvas vies snceutbvroenth en daeeaoyooela tereamgureeass 15 
5.2.1 VS TOR sAUr Cra lt ooo cea5 ie sae ce daaieoes cedgsassedecks seas abcess out ods hpgsdededeecbig sues saabiaeeeds Wawbe esas 15 
5.2.2 Traflic: Aware: Planners ..s.csazcics seven tosasvncbnscuasicsvateds sonevsdebvoateosaeontendeveatateatoauededsssboedoseaentberoeses 16 
5.2.3 COMMUNICATIONS \.2 566.5. csesseetcceseckessttesstecetenceassvcyeuseuswatesenceusscestvassesuceovacestubteaveeeeeaee secksdnoipes 16 

G.. “Test: Method seasceuvsisvcesscvscedia siaccd ss cas coast ineongs sa bustde can cetaaceaccuaetas vei ghloacesdeata edd sd seaccunioacanuenivoneyoiseendcth owt 17 
6.1 PATUCI PANS se.ctesvssttesvescsteccessccelersenssuetoattesvevertebevsaccsceesennsestpattesveuseteveessccesetbuus ceuboasdesvengebecevsgcentects 17 
G2 PrOC@MUIG ss ssctevesie vi satsedenscadestascidatevedoussvacssnw sans igucsdes cuba Saas sad couassauvia sau apleaceescobas suselavecedesuabbiagesiavase 17 
6.3 DOEMOMNStrAtlON SCONALIOS!...- ssscc eaves decrees covstesedeasexsconskdeaveceove ce ccusvessiveves bees ebtasesvtvoysace savecederonvences 18 
6.3.1 Scenario 1 — Weather-Clear Dynamic Re-Routing ......... ee ceeeesesecseeeeeeeceeeceseceeeeeeesecneeenees 19 
6.3.2 Scenario 2 - Aircraft Specific Re-Routing and Electronic Negotiation ............ cesses 20 
6.3.3 Scenario 3 — Flow Management............c:cccssesssecssecsseceseceseceeceeseseeeceneeeeecessecseecsaecaeceseeeseeees 21 
6.3.1 Scenario 4— Dynamic Re-Routing, On-Demand Metering, and Flow Management......... 21 

Po CRROSUILS «0s cs caeen'stonta'evoynasite ota 0ee nies be sutase ts vader terhvseadeusnusetevvenae'Shevsapevsvnvansiist’ toy duce sundunlapeverevellstesubes nese 23 
7.1 Scenario Qualitative Results .........ccccecsesssssccccscscssssscsscccscsesssssessssecssssssssssssesceesessssesesesseeeeeeea 23 
7.1.1 Controller Post-Scenario Questionnaire ReSUItS .............cccecccessscecesssececesssececesssececsenseeeceens 24 
7.1.2 Pilot Post-Scenario Questionnaire ReSUItS ............c cc ccsesccceessececeessececeesseceeessececeesssceceessaeeees 27 

7.2 DISCUSSION: SESSION SUMUMALY: 065. eck. ces cb vsced eevncedsceeuteeesevenses ev vuttseveucaseceuetecebevtestevtunste cv vvttaecevvsecees 30 
7.2.1 TBO Operational Discussion .............s:ccsscsssssrssensssssscenscenscesecesecescesecesstesenesensesnecnsceneseseees 30 
7.2.2 TBO Technological DisCussion ...............:csscssssssssssscesscssscssccsssesencssncesnsesnsesnsscenscenscensseseees 38 
To TBO Procedural Discussion ............scssssssssscsesseseseceseseeeeeeecssecseencesecseeeeeesecsaeeaeeeenaecaeeneeass 40 
7.2.4 General COMMENtS so. 5 occas cesses tase loa Sea sa dasta acess gu cota ece goes cases otubontceg tutesat thtaescntutea sueewe ents 43 

e emmme 0) 0 ed 1103) (9) 0 on ge ee 43 
OQ) LRELCTENCES viicsssecieesdesacejhosc duck sssouccysosstuwtevssuntersenloneesatvenesioesavensavisuesenielss osbe¥aee oso ausevbs sndeul ovsousea es aaztenpesbecy 46 
Appendix A: Post Scenario QuestiOnmaires ............ssccssscesscesscessceeseesseeeseeenecsaecsaecsecesecesecseseseneeenesenteeneeenees 47 
Appendix B: Discussion Questions............:ccsssssscssscesscescssscssccsssessssssssesnseonsesnseeseseseessceseesenesensesnssonsesnees 48 
B,1 Operational! Questions. ws: fcc, scecssiiesscacdeseseeasteiecadesesersads cbaagudevesteateven test vcanadascedTasts Woeeasdesrseselusiaseateaeed 48 


Bet -GontrollersandPil@t i212 si.c5 esi re sscdeve ov A iosetes ecg vbovseSiuet is vesvecncegasl sively) Gic blue sat eau Saeeaderaieed ed bectde 48 


B72: COMO GR 2 csce 0 oSeczcee bec ei sesowestecengetevss ces u coven swsbeee ee okee ta eeae tee vee taste earovacte vere 48 


BB Pilot acess dts ee avast dete ac asad tases Bows tata te es eet I oe a ese eh sete a a Bie 48 
Bi2 “Technological ‘Questions vi..icccsscissfusceans che cots cc cetecoveseveccecheceses tedecesaneaue oveacevedssabdvacucuhaacsceubtuscteetneseses 48 
B:2.1 Controller and {PiU Ot css sicceseecicecsns cei csdebss cots tia eed adciacedsnees Seas cde cesuve cece ubatnc odseain Ceatbads cosueeswectuactne sds 48 
B; 2.2) -GOntrollet ceicecsivescceSessceethteesbeesvatbeesshas oebateds tha seasetese Veena ra seasbun ts twantitevazetute teesbhaseasbeeneteeeanaseesetets tes 49 
Bid Bs PIO ae es ote t ea Sack shave Ea esses STS a tee ahs REN ae sch he ade RO ERE SS Bae 49 
B.3 Procedural QueStiONs............ccccssssscccesssssssssscscceccssssssssssscsescsssesssssssssscessessssssssssecesseesssesessesseseseseas 49 
B.3it “Controller and (Pilots. css cise ts tes Radevecessss'ebe cabeesedaads vee Tasks ves skedsveccssttviesaude veevaet vevsieisvevcseliviedacse voees 49 
A eo Pr PCO) 01k 0) UK nae ee 49 
| Yo Be 21 C0) aes RR RPP 49 


Acronyms and Symbols 


4D 

4DT 
ABP 
ACARS 
ADS-B 
ADS-C 
A-IM 
ANSP 
AOC 
ASTOR 
ATC 
ATOS 
CDM 
CDU 
CPDLC 
Data Comm 
DDS 
DRNAV 
DRNP 
EDST 
EPP 
ETA 
FAA 
FCA 
FMS 

IM 
JPDO 
LoS 
MACS 
NAS 
NASA 
NextGen 
RNAV 
RNP 
RPFMS 
RTA 
RTCA, Inc. 
SD 

SME 
STA 
TAP 
TASAR 
TBFM 
TBO 
TBO-TIGAR 
TMC 
TMU 
UPRR 
WX 


4-Dimensional 

4-Dimensional Trajectory 

Achieve-By-Point 

Aircraft Communications Addressing and Reporting System 
Automatic Dependent Surveillance - Broadcast 
Automatic Dependent Surveillance - Contract 
Advanced Interval Management 

Air Navigation Service Provider 

Airline Operations Center 

Aircraft Simulation for Traffic Operations Research 
Air Traffic Control 

Airspace and Traffic Operations Simulation 
Collaborative Decision Making 

Control Display Unit 

Controller Pilot Data Link Communications 
Data Communications 

Data Distribution System 

Dynamic Area Navigation 

Dynamic Required Navigation Performance 

En Route Decision Support Tools 

Extended Projected Profile 

Estimated Time-of-Arrival 

Federal Aviation Administration 

Flow Constrained Area 

Flight Management System 

Interval Management 

Joint Planning and Development Office 

Loss of Separation 

Multi-Aircraft Control System 

National Airspace System 

National Aeronautics and Space Administration 
Next Generation Air Transportation System 
Area Navigation 

Required Navigation Performance 

Research Prototype Flight Management System 
Required Time-of-Arrival 

Radio Technical Commission for Aeronautics 
Standard Deviation 

Subject Matter Expert 

Scheduled Time-of-Arrival 

Traffic Aware Planner 

Traffic Aware Strategic Aircrew Requests 
Time Based Flow Management 
Trajectory-Based Operations 

TBO Toolkit for Integrated Ground and Air Research 
Traffic Management Coordinator 

Traffic Management Unit 

User-Preferred Re-Route 

Weather 


iii 


1 Abstract 


Trajectory-based operations (TBO) is a key concept in the Next Generation Air Transportation 
System transformation of the National Airspace System (NAS) that will increase the predictability 
and stability of traffic flows, support a common operational picture through the use of digital data 
sharing, facilitate more effective collaborative decision making between airspace users and air 
navigation service providers, and enable increased levels of integrated automation across the NAS. 
The National Aeronautics and Space Administration (NASA) has been developing trajectory-based 
systems to improve the efficiency of the NAS during specific phases of flight and is now also 
exploring Advanced 4-Dimensional Trajectory (4DT) operational concepts that will integrate these 
technologies and incorporate new technology where needed to create both automation and procedures 
to support gate-to-gate TBO. A TBO Prototype simulation toolkit has been developed that 
demonstrates initial functionality that may reside in an Advanced 4DT TBO concept. Pilot and 
controller subject matter experts (SMEs) were brought to the Air Traffic Operations Laboratory at 
NASA Langley Research Center for discussions on an Advanced 4DT operational concept and were 
provided an interactive demonstration of the TBO Prototype using four example scenarios. The 
SMEs provided feedback on potential operational, technological, and procedural opportunities and 
concerns. After viewing the interactive demonstration scenarios, the SMEs felt the operational 
capabilities demonstrated would be useful for performing TBO while maintaining situation 
awareness and low mental workload. The TBO concept demonstrated produced defined routings 
around weather which resulted in a more organized, consistent flow of traffic where it was clear to 
both the controller and pilot what route the aircraft was to follow. In general, the controller SMEs 
felt that traffic flow management should be responsible for generating and negotiating the operational 
constraints demonstrated, in cooperation with the Air Traffic Control System Command Center, 
while air traffic control should be responsible for the implementation of those constraints. The SMEs 
also indicated that digital data communications would be very beneficial for TBO operations and 
would result in less workload due to reduced communications, would eliminate issues due to language 
barriers and frequency problems, and would make receiving, loading, accepting, and executing 
clearances easier, less ambiguous, and more expeditious. This paper describes an Advanced 4DT 
operational concept, the TBO Prototype, the demonstration scenarios and methods used, and the 
feedback obtained from the pilot and controller SMEs in this focus group evaluation. 


2 Introduction 


Over the next 20 years, domestic revenue passenger miles are projected to increase 2.1% per year 
while international revenue passenger miles are forecast to increase 3.5% per year [FAA, 2016]. 
Furthermore, explosive growth in unmanned aerial systems in the National Airspace System (NAS) 
and increases in general aviation brought about by on-demand mobility are foreseen to push the 
overall traffic demand far beyond the original Joint Planning and Development Office (JPDO) 
predictions for 2025. New types of aircraft utilizing the airspace not only create a capacity concern 
in the NAS but will also create a large disparity in vehicle performance and equipage. New 
environmentally-friendly and clean-energy vehicles may require significantly different flight profiles 
to realize their environmental benefits. There is a growing environmental need for legacy aircraft to 
fly low-noise, fuel-efficient flight profiles to reduce airport noise and emissions in all weather and 
traffic conditions. Access to space and future supersonic transports must also be accommodated. 
This disparity, coupled with inconsistent use of ground automation, often leads to inefficiencies in 
the NAS during both nominal and off-nominal (e.g., disruptive weather or unusually high traffic) 
operations, creating unnecessary delays that result in lost revenue for aircraft operators, lost time for 
passengers, and adverse environmental impacts. 


The National Aeronautics and Space Administration (NASA) has developed trajectory-based systems 
to improve the efficiency of the NAS. Many of these systems are targeted at a specific phase of 
flight, such as departures, cruise, or arrivals. An Advanced 4-Dimensional Trajectory (4DT) concept 
will integrate these technologies and incorporate new technology where needed to create both 
automation and procedures to support gate-to-gate trajectory-based operations (TBO). The primary 
objective of Advanced 4DT is to accelerate the implementation of a trajectory-based system that both 
aligns with, and extends upon, the Federal Aviation Administration’s (FAA’s) Next Generation Air 
Transportation System (NextGen) vision. The proposed Advanced 4DT system will improve the 
efficiency of the NAS, reduce fuel and noise emissions, and reduce system delay while maintaining 
or improving the current level of safety by enabling strategic planning, flexible user preferred re- 
routing, electronic trajectory negotiation, and trajectory synchronization among all relevant systems 
and stakeholders. 


NASA has developed an Advanced TBO Prototype simulation toolkit that demonstrates initial 
functionality that may exist as part of an Advanced 4DT TBO concept. The objectives of the 
Prototype were to develop an initial TBO simulation capability leveraging existing tools where 
possible and prototypes as needed; develop an initial set of requirements for ground and airborne 
systems for performing TBO operations; and engage stakeholders and subject matter experts (SMEs) 
as part of a focus group evaluation. The SMEs participated in discussions of an Advanced 4DT 
operational concept and were provided an interactive demonstration of the TBO Prototype using four 
example scenarios. This report describes an initial Advanced 4DT operational concept, the TBO 
Prototype, test method, and the feedback obtained during the focus group evaluation. 


3 Advanced 4DT TBO Concept 


In current day operations, air traffic controllers manage separation between aircraft using tactical 
speed, heading, and altitude commands transmitted to the aircraft via voice communication. The 
controller who is issuing these commands often does not have a full picture of the impact of those 
commands on downstream flows and constraints. When large perturbations, such as convective 
weather, force aircraft to be re-routed, traffic managers and controllers revert to pre-planned 
playbooks which may not be optimal for a given situation. Additionally, current decision support 
tools designed to help controllers and traffic managers meter aircraft cannot be used once aircraft are 
vectored off of a known route. There is a need for new air traffic management automation that is 
robust to large perturbations such as convective weather, enables fuel efficient and flexible user- 
preferred re-routes (UPRRs), and enables strategic planning. A key concept in the NextGen 
transformation of the NAS, which was designed to address these problems, is the implementation of 
gate-to-gate TBO [JPDO, 2010; JPDO, 2011; and Johnson and Barmore, 2016]. 


TBO utilizes 4DTs that span all phases of flight, from pushback to arrival at the gate, as the basis for 
planning and executing all flight operations. The mode of operations and the requirements of the 
airspace dictate the specificity of the trajectory. As the flight progresses, more detail is added to the 
downstream trajectory as needed for flow management, resource allocation, and separation assurance. 
Trajectories are negotiated between the operator and the Air Navigation Service Provider (ANSP), 
both preflight and during the flight, as conditions change, to satisfy the operators’ business objectives 
and preferences while meeting ANSP constraints. User preferences are accommodated to the greatest 
extent possible, and trajectories are constrained only to the extent required to maximize capacity and 
accommodate demand, or for other concerns, such as safety, security, or the environment. In high- 
density or high-complexity airspace, the ANSP may need to limit the aircraft to a given published 
airway and assign constraints at specific points; while in low- to medium-density airspace, a wind- 
optimal route defined by a series of arbitrary points in space identified by latitude and longitude might 


be negotiated. The use of precise 4DTs dramatically reduces trajectory uncertainty and enables the 
airspace to be used more effectively to safely accommodate high levels of demand, reduce 
environmental impacts, and maximize the use of capacity-limited airspace and airport resources. 
Furthermore, TBO will increase the predictability and stability of traffic flows, support a common 
operational picture through trajectory synchronization, facilitate more effective collaborative 
decision making between airspace users and the ANSP through electronic trajectory negotiation, and 
enable increased levels of integrated automation across the NAS. Because TBO is a significant 
paradigm shift in the way flights are managed, the transition to TBO will occur gradually over time 
as flight deck and ground-based automation is developed and as supporting infrastructure is deployed. 
As such, an evolutionary path from today’s air traffic system to a future TBO system must be clearly 
defined. 


The FAA is committed to moving toward TBO and is making significant progress in working with 
EUROCONTROL to define and implement globally harmonized standards for key infrastructure to 
support the transition to TBO, such as Automatic Dependent Surveillance — Broadcast (ADS-B), 
digital Data Communications (Data Comm), and System-Wide Information Management. Near- and 
mid-term NextGen Collaborative Air Traffic Management and traffic management tools, for use by 
either the ANSP or the airline dispatchers, as well as flight deck-based technologies, are already 
moving towards some of the capabilities and benefits that full TBO is expected to provide. The FAA 
is developing a concept of operations for TBO and has conducted a simulation demonstration of 4DT 
operations that included Dynamic Required Navigation Performance (DRNP) and Advanced Interval 
Management (A-IM). DRNP is a concept for re-routing aircraft by the ANSP by up-linking a fully- 
specified 3-dimensional path clearance along with the Required Navigation Performance (RNP) 
values necessary to allow for conformance monitoring onboard the aircraft, and A-IM is an extension 
of Interval Management (IM) for pair-wise spacing that can be used in conjunction with other 
operations, such as along DRNP routes. 


NASA’s Advanced 4DT concept focuses on combining these same capabilities with fewer 
restrictions. A new capability assists the traffic manager in identifying aircraft which will be 
impacted by convective weather and proposes re-route options. Proposed re-routes are sent to the 
radar controller for consideration and issuance to aircraft. These re-routes are designed to be free 
from weather conflicts for a prescribed period of time. The re-routes can also be constrained to a 
limited number of off-route named fixes or be a series of latitude, longitude points, and can be 
augmented by RNP values where necessary. The former can be communicated via voice clearance 
while the later requires the receiving aircraft to be equipped with Controller-Pilot Data Link 
Communications (CPDLC). These re-routes are also supplied to a scheduling system, such as Time- 
Based Flow Management (TBFM), in a way that supports metering aircraft to any point in space, or 
along ad-hoc routes. 


Aircraft equipped with route optimization tools [Ballin and Wing, 2012] have the ability to initiate 
trajectory negotiations from the flight deck. The aircraft are able to develop user-optimized trajectory 
changes and send those to the ground automation as a re-route request. These re-routes may include 
latitude and longitude defined points and the trajectory negotiation process is conducted via data 
rather than voice communications. This negotiation process may require the input of the Airline 
Operations Center (AOC) depending on the magnitude of the route change. 


For sufficiently equipped aircraft, data communications are also used to share trajectory information 
from the aircraft to the ground automation platforms using the Extended Projected Profile (EPP) 
message. The EPP may be used within several air traffic management and control functions, 
including conflict detection, trajectory synchronization, and estimated times-of-arrival (ETA) 


derivation. It is expected that the ETA from the aircraft will be a better representation of the aircraft’s 
capabilities than an ETA calculated by the ground automation’. 


The Advanced 4DT concept will support improvements in execution of metering, merging, and 
spacing functions. The ground automation can use the ETAs from the 4DT at key points to support 
metering. Once aircraft are within the freeze horizon of a metering scheduler, the controller has 
available the options to provide speed advisories to the aircraft to meet the Scheduled Time-of-Arrival 
(STA); to issue a Required Time-of-Arrival (RTA) where the aircraft will use their Flight 
Management System to manage their speed to meet their STA; or to issue an A-IM clearance where 
the aircraft manages their speed to achieve and maintain a spacing relative to their leading aircraft 
that matches the spacing needed at the meter fix. The controller’s decision support tools will 
recommend the appropriate action including preparing CPDLC messages to be sent to appropriately- 
equipped aircraft. 


The advanced 4DT concept is seen as a stepping stone towards full gate-to-gate TBO. 


4 TBO Prototype 


A TBO Prototype capability was developed to allow for demonstrations of some of the functionality 
of an Advanced 4DT concept. This Prototype development targeted the following set of objectives: 
e develop an initial set of requirements for ground and airborne systems for performing TBO 
operations; 

e develop an initial TBO simulation capability leveraging existing tools where possible and 
rapid prototypes as needed; 

e demonstrate specific concept elements to stakeholders and subject matter experts to obtain 
feedback on the concept; 

e and identify gaps in the existing tools and simulation capabilities. 


The capability implemented in the TBO Prototype was derived from the high-level design shown in 
Figure 1. The idea illustrated in the figure is that trajectory constraints are generated by the air traffic 
system (largely by traffic flow management, e.g., by the TBFM tool) for each aircraft. Those 
constraints may be subject to negotiation or collaborative decision making before being passed on to 
air traffic control (ATC) for issuance to the appropriate aircraft based on the available communication 
mechanisms, either voice or CPDLC. In turn, those aircraft that are equipped with Data Comm share 
their reference trajectory — which adheres to the imposed constraints — with the ground automation 
systems for synchronization and monitoring via Automatic Dependent Surveillance - Contract (ADS- 
C) reports. In addition, equipped aircraft can use Data Comm, such as the Aircraft Communications 
Addressing and Reporting System (ACARS), to more easily coordinate trajectory change requests 
with the AOC and the ANSP. 


The Prototype was targeted at demonstrating functionality that could be available in a mid-term time 
frame (2025-2035). In that regard, the Prototype had the ability to simulate both legacy aircraft 
equipage as well as more advanced TBO equipage (which includes Data Comm and the sharing of 
ADT information). 


! Validating this assumption and assessing the impact of combining aircraft-calculated and ground-calculated ETAs 
is a point for future research. 
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Figure 1. High-Level Inspirational Design for the TBO Prototype. 
Prototype Architecture and Capabilities 


The TBO Prototype integrated three existing simulation systems with a newly-developed simulation 
capability. The Airspace and Traffic Operations Simulation (ATOS) [NASA, 2016] is a simulation 
capability that includes a high-fidelity aircraft simulation, known as the Aircraft Simulation for 
Traffic Operations Research (ASTOR), which emulates the functions of a modern commercial 
airliner. The ASTOR capabilities include: a Research Prototype Flight Management System 
(RPFMS), Data Comm, multiple RTAs, and more. The capabilities were augmented for the TBO 
Prototype work. The Traffic Aware Planner (TAP) is a route optimization tool that continually 
searches for route changes that produce time or fuel savings relative to an aircraft’s current route. 
This capability was used in conjunction with the ATOS simulator to generate UPRR requests. The 
Multi-Aircraft Control System (MACS) is a software package that emulates much of today’s air 
traffic control functionality. MACS can be used with the TBO Prototype to display the position of 
simulated aircraft on an air traffic controller’s scope; however, MACS was not enabled for this focus 
group evaluation. Finally, the Trajectory-Based Operations Toolkit for Integrated Ground and Air 
Research, or TBO-TIGAR, was a newly developed simulation capability that supported both 
simulation of lower fidelity aircraft as well as prototype implementations of various TBO capabilities 
or functions; these included: CPDLC, ADS-C, DRNP re-route generation, and more. The TBO- 
TIGAR and ATOS simulations used a communications interface that leveraged an open-source Data 
Distribution Service (DDS) protocol. Figure 2 shows an architectural and functional diagram of the 
TBO Prototype. The following sections describe each of the TBO Prototype capabilities and 
functions developed for this activity in more detail. 
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Figure 2. TBO Prototype Architecture and Functionality Description. 
Dynamic Area Navigation/Required Navigation Performance 


The TBO Prototype included the ability to dynamically generate re-routes in the form of Dynamic 
Area Navigation (DRNAV) routes. DRNAVs are dynamically generated area navigation (RNAV) 
re-routes - navigating by means of named fixes and navigational aids - but do not contain any 
navigational performance requirement. The DRNAV functionality allowed for the on-demand 
drawing of these re-routes and assigning those as clearances to candidate flights via voice or Data 
Comm. Additionally, the capability allowed for DRNAV re-routes where the initial and final re- 
route waypoints were on a flight’s active flight plan as well as the ability to connect an existing flight 
plan to a DRNAV re-route in space, where the initial and final re-route waypoints were not part of 
the active flight plan. Appropriate re-route clearances were automatically generated by the DRNAV 
capability. 


The TBO Prototype also included the ability to automatically generate DRNP re-routes. DRNPs are 
based on the similarly-named concept of operations by the FAA [FAA, 2014] and are targeted at 
improving the flexibility of the NAS. A DRNP [RTCA, 2016a and RTCA, 2016b] is a re-route 
defined by a set of waypoints (which can include latitude/longitude points), RNP data for the re-route 
on a leg-by-leg basis, and fixed-radius-transitions or radius-to-fix legs to fully define the tum 
geometries along the re-route. The DRNP capability implemented in the TBO prototype provided the 
ability to automatically generate a DRNP re-route that was clear of weather given the following 
information: starting waypoint, ending waypoint, re-route activation time, re-route duration, and an 
average groundspeed for the re-route. The capability computed a DRNP re-route that satisfied these 
input parameters and avoided a set of weather cells, taking into account each cell’s expected 


6 


4.3 


4.4 


movement with time. This prototype capability also provided information about the flights in the 
simulation that were candidates for the DRNP re-route solution by evaluating each’s flight’s 
geometric and temporal feasibility in reaching and executing a potential re-route clearance for the 
DNRP re-route solution. Appropriate re-route clearances were automatically generated as needed 
and could be sent to data link equipped flights. Flights that received DRNP re-routes through Data 
Comm were assumed to have the ability to automatically load the re-route clearance into the Flight 
Management System (FMS). 


ADS-C and Extended Projected Profile 


The sharing of trajectory information between an aircraft and ground automation was accomplished 
via a 4DT in the form of an EPP, as defined in RTCA DO-350A [RTCA, 2016a] and RTCA DO- 
351A [RTCA, 2016b]. The EPP consists of up to 128 trajectory points, each containing a set of 
required and optional fields. The EPP data is one element of a report message that is generated based 
on an ADS-C contract. The prototype ADS-C implementation allowed for trajectory sharing of EPP 
information on a periodic basis for aircraft equipped with an FMS and Data Comm. The EPP 
trajectory shared by equipped aircraft was used in four functions by the TBO Prototype: available for 
graphical display by the ground automation, to update flight plan information in ground automation, 
for advanced interval management clearances, and to derive ETAs in time-based metering schedulers. 


Advanced Interval Management 


The TBO Prototype included an implementation of an A-IM capability. A-IM is a future flight deck 
concept that will enable an aircraft to either achieve or maintain a precise spacing interval behind 
another aircraft [Barmore et al., 2016]. A-IM builds on the initial version of IM that is currently 
being transitioned to industry stakeholders. The IM system will support merging and spacing of 
aircraft on published routes during both the en route and arrival phases of flight. A-IM will add the 
capability to use 4DTs for the target aircraft that are communicated to the IM aircraft through Data 
Comm. A-IM will also increase the types of IM operations that can be conducted. Some of the new 
operations that are being considered are: support for dependent parallel runways, paired approaches, 
and Pairwise Trajectory Management. 


The prototype A-IM functionality in the TBO-TIGAR ground automation enabled a controller to 
automatically generate an A-IM clearance through a set of simple inputs: IM aircraft, target aircraft, 
achieve-by-point (ABP), termination point, and spacing interval. Given these inputs, the ground 
automation in TBO-TIGAR composed the appropriate data link clearance for controller review and 
issuance to the IM aircraft. These clearances contained the 4DT information for the target aircraft 
obtained from that aircraft’s last shared EPP. The inherent assumptions under this prototype A-IM 
implementation were that: both the target aircraft and the IM aircraft had Data Comm, the target 
aircraft was under an ADS-C contract to provide EPP information, the aircraft receiving the clearance 
had an IM capability, and that the EPP information for the target aircraft was sent only once (with 
the clearance) to the IM aircraft. 


A prototype A-IM capability and algorithm was implemented for the TBO-TIGAR simulated aircraft. 
This capability allowed these aircraft to receive and parse the A-IM clearance through a data link 
message and to manage the pair-wise spacing to an ABP. This initial implementation only allowed 
for precise spacing clearances to the ABP, where the aircraft was expected to reach the required 
spacing at or before the ABP and the operation terminated when the ABP was reached. The prototype 
IM algorithm computed an ETA for the target aircraft by using that aircraft’s 4DT, applied an along- 
track correction to that 4DT to account for staleness of the 4D information, and computed an RTA 
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for the IM aircraft at the ABP by adding the required spacing to this adjusted ETA. An RTA tolerance 
of 5 seconds was used by the IM algorithm to manage the spacing error. 


Required Time-of-Arrival 


An RTA capability in the TBO prototype allowed RTAs to be issued to specified flights via Data 
Comm. An RTA capability was already available in the ASTOR’s RPFMS and was leveraged 
without modification. A simple, prototype RTA functionality was developed for the TBO-TIGAR 
simulated aircraft targeted for use in the en route phase of flight. The simple algorithm allowed for 
up to a 10 percent change in cruise speed in the flight plan legs leading up to the RTA waypoint, with 
most of the time adjustment being done close to the RTA waypoint. For RTAs originating from a 
time-based metering scheduler, data link clearances with RTA constraints were automatically 
composed and presented to controllers for issuance to a flight. 


User-Preferred Re-Route Requests 


The TBO Prototype included the ability for the flight crew to send a request for a UPRR to ground 
automation via DataComm. This prototype capability used a combination of the ASTOR simulation 
and the TAP tool. The TAP tool provided the flight crew with route change advisories (lateral, 
vertical, or lateral and vertical) that were optimized for time or fuel savings, given the active route 
and weather or other constraints. These route change advisories could be entered by the flight crew 
into the FMS as a route modification and shared with ground automation, thereby establishing a 
UPRR request between the flight deck and the ground automation. The UPRR request was 
transmitted in the form of a 4DT, leveraging the same format as an EPP trajectory. UPRR requests 
were received by ground automation and were available to the air traffic controller in graphical form 
as lateral and vertical flight profiles. 


Time-Based Metering and Scheduling 


A simple time-based metering and scheduling capability was prototyped in the TBO-TIGAR 
simulation. The time-based scheduler could be configured to manage the traffic to one or multiple 
destinations and pass through one or multiple meter points. The scheduler managed the traffic flow 
through the set of meter points by computing appropriate STAs for each flight based on each flight’s 
ETA and the required spacing interval. The scheduler used a horizon 30 minutes prior to the meter 
points where each aircraft’s STA would be frozen. Each flight was assigned an STA equal to or at 
some time later than that flight’s ETA. The ETAs within the scheduler were computed using either 
a simple trajectory prediction based on the flight plan information, or the shared EPP information if 
that data was available. Although simple in its implementation, the prototype scheduling algorithm 
mimicked some of the functionality available in the FAA’s TBFM tool. 


Communications 


The TBO Prototype emulated the major components of a Data Comm environment. CPDLC allowed 
for the ground automation to send clearance messages to flights and for flights to provide an 
appropriate response to ground automation. Vehicle state information was broadcast by each flight 
via a true state message (no ADS-B error) and was received by ground automation and flights with 
assumed ADS-B-In capabilities. The Aeronautical Telecommunication Network, Baseline 2, Data 
Comm standards [RTCA, 2016a & 2016b] were used to create an emulation of the ADS-C capability 
to enable the broadcast of EPP trajectory information from equipped aircraft to the ground 
automation. 


Voice clearances were implemented using simulation messages — similar to the data link equipped 
aircraft — because all aircraft were simulated and did not have live flight crews. The exception was 
the single ASTOR aircraft, which did have live pilot support but that aircraft was data link equipped 
and did not require voice clearances. All communications (CPDLC, ADS-C, and state information) 
between the ASTOR aircraft and the TBO-TIGAR ground automation used the DDS communication 
interface. 


5 System Description 


The Advanced 4DT TBO Prototype system implementation was comprised of ground-based systems, 
airborne systems, and the communication systems between them. The prototype system was 
configured in the laboratory environment with a single aircraft workstation and a single ground-based 
workstation as seen in Figure 3. The aircraft workstation included the ASTOR simulated aircraft and 
the TAP route optimization application. The ground-based workstation included the TBO-TIGAR 
prototype tool with the various functions described in Section 4. In this section, the various interfaces 
implemented to exercise the prototype functionality will be described. 
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Figure 3. Advanced 4DT Prototype System in the Laboratory Environment. ASTOR Simulation 
and TAP Application (Top) and TBO-TIGAR Ground Automation Tools (Bottom). 


5.1 TBO Automation Tools 


The TBO-TIGAR prototype ground automation system included the tools necessary to simulate a set 
of aircraft, to assess the state of the simulation and generate and issue clearance instructions, and to 
generate trajectory path and time constraints. This suite of tools can be respectively categorized in 
three components: a flight manager, ATC automation, and flow management tools. Each of these 
components will be described in the following sections. It should be noted that the goal of this 4DT 


5.1.1 


Prototype was not to define user interface requirements or design specific interfaces for ground 
automation tools but rather to demonstrate the prototype functionality. As such, the interfaces to the 
ground automation tools were simple engineering views into each of the simulation components. 


Flight Manager 


The flight manager was a low- to medium-fidelity flight simulator that generated flight trajectories 
for a set of flight plans in a scenario. It managed the trajectory of each simulated flight and collected 
and displayed aircraft state information for aircraft connected in from other simulations (i.e., the 
ASTOR aircraft). The interface to the flight manager was provided by a plan view of the simulation 
environment as seen in Figure 4. The position of each aircraft in the simulation was shown within 
the selected zoom window. Also depicted was the trajectory for each aircraft (blue lines), any active 
weather hazard regions (yellow polygons), and the Center airspace boundaries (light grey lines). This 
plan view also provided the menu bar for controlling the simulation environment (top of Figure 4) as 
well as the controls for simulation time and speed (bottom of Figure 4). 
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Figure 4. TBO-TIGAR Plan View Display. 


The flights simulated by TBO-TIGAR used a low-fidelity trajectory model. A kinematic trajectory 
comprised of constant speed or constant acceleration legs was generated for each flight using a simple 
vertical and speed profile. The vertical flight profile emulated a single, constant vertical climb rate 
to a cruise altitude and a single, constant vertical descent rate, while the speed profile assumed 250 
knots below 10,000 feet and a fixed cruise groundspeed above 10,000 feet. Each flight’s initial 
trajectory was generated from a scenario file to follow a flight plan defined by a set of navigational 
aids, navigational fixes, and/or instrument departure and arrival procedures. 


The TBO-TIGAR tool had the ability to emulate all of the TBO Prototype functions for any flight, 


although an equipage field was used to differentiate between fully- and lesser-equipped flights. The 
two designations for equipage were TBO-equipped and non-TBO-equipped to distinguish between 
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aircraft equipped with Data Comm and those not so equipped, respectively. The non-TBO-equipped 
flights were assumed to have: voice communications (emulated via messaging in the TBO-TIGAR 
tool), single RTA capability, RNAV, and a conventional FMS capability with lateral and vertical 
guidance modes. The TBO-equipped flights were assumed to have all of these capabilities plus: Data 
Comm with CPDLC and ADS-C capabilities, dynamic re-routes to include latitude/longitude defined 
waypoints (emulated DRNP without enforcing the RNP conformance), and an advanced FMS 
capability. This advanced FMS capability provided the ability to generate EPP information from the 
reference trajectory, to auto-load Data Comm clearance messages, and to load and execute A-IM 
functions. 


The plan view provided by the flight manager allowed for other user interactions and for the display 
of specific re-route information. A user could utilize a mouse to select any aircraft on the plan view; 
that aircraft’s trajectory color would be shown in red. By right-clicking a mouse on the plan view, 
the user could select from a list of available functions such as: show information about a nearby 
navigational aid or fix, display the location of the five closest navigational aids or fixes, control the 
drawing of a DRNAV re-route, among others functions. Once initiated, the drawing of DRNAV re- 
routes was a simple drag-and-drop operation on the plan view. The plan view also depicted the DRNP 
re-routes that were generated by the DRNP re-route generation tool. Examples of DRNAV (green) 
and DRNP (magenta) re-routes are shown in Figure 5. 


41.90"N- 


41.47°N- 


Figure 5. Example DRNAV (Green) and DRNP (Magenta) Re-Routes on the Plan View. 
5.1.2. ATC Automation 


The ATC automation component of TBO-TIGAR provided information about the status of each flight 
in the simulation and allowed for clearance messages to be generated and sent to each flight. An 
ATC user interface showed the flight plan information for each flight (top of Figure 6). Within this 
ATC view, CPDLC messages with revised clearances or instructions could be generated and sent to 
a constraint action queue for review before being issued to the appropriate flight (middle of Figure 
6). These instructions included DRNP and DRNAV re-routes, RTA assignments, and ADS-C 
requests for EPP information. Shortcut buttons were available to aid in the building of these 
instructions or clearances. The “RNAV — CPDLC” button auto-populated a clearance message 
string from an available DRNAV re-route. The “Connect to D-RNAV” button checked the feasibility 
of amending an existing flight plan with a DRNAV re-route when the first and last waypoints in the 
re-route were not already part of that flight plan. The “Check If RNAV Clear Of WX” button 
evaluated whether a flight entering an available DRNAV re-route at a specified time and with a 
specified groundspeed would be in conflict with any weather cell. The “Find WX Status All” button 
compared each flight’s trajectory against the active weather cells to identify any weather conflicts, 
their expected time of occurrence, and whether these flights were candidates for any existing DRNP 
re-routes, as depicted in Figure 7. Finally, the “IM Tool” button provided a utility for generating an 
A-IM clearance based a small set of input parameters, as seen in Figure 8. All clearances and 
instructions sent to each flight, including their respective responses, were available in the message 
log (bottom of Figure 6) in the ATC view. 


11 


The ATC automation also provided a dedicated window for the display of detailed flight information. 
For any flight selected from the ATC view or from the flight manager’s plan view, a flight 
information window similar to that in Figure 9 was displayed. The flight information window 
provided an engineering view of each aircraft’s state, its flight plan information, as well any EPP 
information available for that flight. Both a textual version of the EPP information as well as a 
graphical representation of the lateral and vertical profiles were available in the flight information 
window for TBO-equipped flights. The lateral and vertical profile views within the flight information 
window were also used to display re-route requests that were received from flights in the form of a 
ADT. 


FlightPlan 
|00:35:00 05:28:46 KLAX./.OBK..UNBAR,.COYNU..CRL..COHOW..SURLY..JHW..HOXIE..DMACK..STENT..MAGIO..LVZ. JENNO..HART... |AVAILABLE 
\01:45:00 06:56:16 KSFO./.BFF..ONL..KATES..FOD..VIGGR..DBQ..COTON..OBK..UNBAR..COYNU..CRL..COHOW..SURLY..JHW..HOX... |—- 
AAL192 KLAX KBOS 01:00:00 06:33:22 KLAX./.GEP..GRB..TRUIZ..KBOS AVAILABLE 
AAL30 KLAX KJFK |02:35:00 07:29:56 KLAX/.EKR..FROGS..SNY..ELJAY..OBH..PUMKN..JORDY..CAPPR..DBQ..COTON..OBK..UNBAR..COYNU..CRL..C... |—- 
| JAWE18 KPHX KJFK 00:39:00 05:18:42 KPHX./.GIJ..BENJO..CRL..COHOW..SURLY..JHW..HOXIE..DMACK..STENT..MAGIO..LVZ.. JENNO..HARTY..SCOUP..../AVAILABLE 
AWE689 KPHX KEWR = |00:38:20 05:14:49 KPHX./.GIJ..BENJO..CRL..KEEHO..HUDUG..DORET..ZORBO..SLT..FQM..MEGSS..HAYED..RACKI..SWEET..KEWR |AVAILABLE 
DAL1002 KSLC KJFK 01:55:00 05:51:31 KSLC./.DBQ..COTON..OBK..UNBAR..COYNU..CRL..COHOW..SURLY..JHW..HOXIE..DMACK..STENT..MAGIO..LVZ.... |- 
DAL1043 KSEA KJFK |02:10:00 06:55:44 KSEA/.DPR..RWF..HARPI..ODI..SIBER..BRIBE..OBK..UNBAR..COYNU..CRL..COHOW..SURLY..JHW..HOXIE..DMA...|AVAILABLE 
DAL1162 KLAX KJFK |00:33:00 05:30:22 KLAX/.JOT..GIJ..BENJO..CRL..COHOW..SURLY..JHW..HOXIE..DMACK..STENT..MAGIO..LVZ. JENNO..HARTY..SC... |— 
IDAL1262 KLAX KJFK |02:30:00 07:23:47 KLAXJ/.HGO..GLD..LNK..CNOTA..IOW..VORIN. JOT..GIJ..BENJO..CRL..COHOW..SURLY..JHW..HOXIE..DMACK..ST...|— 
DAL1428 KLAS KJFK 02:30:00 06:52:43 KLAS./.PWE..IRK..RBS..AWOKA..DJB..SLT..FQM..LVZ.JENNO..HARTY..SCOUP..MUGZY..STW..LENDY..LGA.KJFK |- 
DAL1894 KPHX KJFK |01:50:00 06:11:04 KPHX.I.CNOTA..IOW..VORIN..JOT..GIJ..BENJO..CRL..COHOW..SURLY..JHW..HOXIE..DMACK..STENT..MAGIO..LV... |AVAILABLE 
DAL2240 KSFO KJFK |00:15:00 05:25:04 KSFO./.OBK..UNBAR..COYNU..CRL..COHOW..SURLY..JHW..HOXIE..DMACK..STENT..MAGIO..LVZ..JENNO..HART...|AVAILABLE 
DAL2340 KSFO KJFK |02:15:00 07:25:04 KSFO./.OCS..BFF..ONL..KATES..FOD..VIGGR..DBQ..COTON..OBK..UNBAR..COYNU..CRL..COHOW..SURLY..JHW...|— 
DAL322 KLAS KJFK |00:55:00 05:24:05 KLAS./.GIJ..PLAIN..GERBS..IDEAS..WOOST..CXR..SLT..LVZ..JENNO..HARTY..SCOUP..MUGZY..STW..LENDY..LG... |—- 
KPDX |02:15:00 07:00:18 KPDX./_.DIK..FAR..BRD..BRDIE..WLSTN..TVC..YXU.JHW..HOXIE..DMACK..STENT..MAGIO..LVZ. JENNO..HARTY..S...|— 
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Figure 6. ATC Communication Hub with Flight Plan List, Trajectory Constraint Queue, and 
Message Log. 
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Interval Spacing Clearance Parameters 
Target Aircraft: 
Achieve By Point: 
Termination Point: 
Spacing Interval (seconds): 


Figure 8. Interval Spacing Clearance Generation Utility. 


Sim Time: 14034.50[s] [03:53:54] 
Plan Aircraft: |UAL1228 | Index:[1224 | 
Start Time: 1510.0 [s] End Time: 18832.9 [s] 
Origin Airport: KSAN Dest. Airport: KEWR 
Position: 41.746°N, 86.542°W, 35000.000 If Velocity: 82. 058 [deg], 459.000 [knot], 0.000 [fpm] 
Status: Active, Plan A/C, **Wx Conflict** Equipage: TBO:RTAIM: 


Flight Plan: SAN.JETTILLOWMA.PGY.BROWS.JLI.TRM.EED.TBC.PWE.JOT.GIJ.BENJO.CRL.KEEHO.HUDUG.DORET.ZORBO.B | i} 


IAR.SLT.FQM.HAYED.RACKI.SWEET.KEWR 


Exec Plan: 


SAN.JETTILLOWMA.PGY.BROWS.JLI.TRM.EED.TBC.PWE.JOT.GIJ.BENJO.CRL.KEEHO.HUDUG.DORET.ZORBO.B |* 
IAR.SLT.FQM.HAYED.RACKI.SWEET.KEWR 


-P:12,N41086350W076032072,2516. HAYED,3766,K459....1100000.,. a 
13,N41007300W075346175,1642,RACKI,3946,K459,000100000, 
-P:14,N41002029W075327303,1576,,3960,.K355,001000000...... 
-P:15,N40589779W075283318, 1402, ,3996,K354,000010000...... 
-16,.N40548617W075136666,1201.,4116,K354,000100000. 
-P:17,N40544671W075122678,1179.,4129.K250,001000000...... 
-P:18,N40496963W074554592,849, SWEET ,4325,K250,.20,,1000000.,. 
isl beca aih act nscatten ota enainriay P:19.N40415500W074101200,2, KEWR.4833,K250....1100000... 
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Figure 9. Flight Information Window. 
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5.1.3 Traffic Flow Management Automation 


The prototype traffic flow management automation tools provided the functionality typically 
available to a traffic flow manager. This grouping of functions to the traffic manager operational 
position is somewhat loose because one of the objectives of this focus group activity was to ask 
participants their recommended function allocation. The prototype functions included a time-based 
metering scheduler capability and a dynamic re-route generation capability. 


The time-based scheduler capability allowed for metering of traffic at a single point or a group of 
points in space. An example of the time-based scheduler can be seen in the timeline of Figure 10. 
This particular scheduler was configured to meter traffic at the group of points DMACK, ETG, and 
SLT as a single meter boundary for traffic destined to the New York area airports. The scheduler 
began computing STAs for each flight at a planning horizon 35 minutes prior to the meter points and 
STAs were fixed once each flight passed a freeze horizon 30 minutes prior to the meter points. The 
left side of this timeline view shows the ETA for each flight, where the “4d” identifier indicates those 
ETAs generated using EPP information. The right side of the timeline view shows the STA for each 
flight as well as the amount of delay absorption required to meet that STA (ie., “AVWE689 1” 
indicates approximately one minute of delay required). At the bottom of the timeline view, a user 
could input the call sign for any flight in the scheduler to view the scheduled time and a button 
allowed that STA to be sent to ATC automation as a proposed RTA constraint for that flight. 


[| NYLFCA —_ roe) 


Time-Based Metering Schedule: NY_FCA 


CallSign Scheduled Time 


UAL1228 04:45:42 Issue RTA | 
— nd 


Ripple Schedule 


Enable Speed Advisories Max Time: 1.0 [hr 


| 
] 
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Figure 10. Example Time-Based Scheduler Timeline View. 
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5.2 


5.2.1 


The dynamic re-route capability in TBO-TIGAR allowed for the generation of weather-clear re- 
routes. The interface for this capability can be seen in Figure 11. By providing a small number of 
parameters specifying the start, end, starting time, duration, and average groundspeed for a desired 
re-route, the tool would identify an efficient re-route around any existing weather constraints. The 
tool would also provide a list of candidate flights based on the flight plans of all active flights and the 
feasibility of the re-route solution for that flight. The re-route solutions included latitude and 
longitude defined waypoints and were assigned turn geometries and leg-specific RNP values to fully 
specify DRNP re-routes. 


[ij Dynamic RNPWindow NN SSSS”S~™~” ce et 


Waypoint 1 | Waypoint 2 Clear DRNP Save DRNP Load DRNP. 


StartTime | Time Window [1200 


Speed Reroute Wx ReCheck Wx Send Reroute ATC Delete From List 


Find WPs Selected Connect To DRNP Advanced Parameters 


StartTime Window Trajectory 


ReRoute Num 


ReachTime CallSign 


Figure 11. Weather-Clear Dynamic Re-Route Generation Tool. 


Airborne Automation 


The aircraft automation systems used in the 4DT Prototype leveraged the ATOS simulation, which 
included the ASTOR aircraft and its sub-systems. The ASTOR aircraft could receive and provide 
responses to Data Comm messages from the ground automation as well as send 4DT information to 
the ground automation. The UPRR generation application, TAP, was used to generate UPRR 
solutions that could be communicated to ATC for approval. The changes that were made to the 
ATOS simulation more closely mimicked the expected implementation in an operational system 
because those changes primarily involved displaying Data Comm messages that have already been 
defined in standards documents. 


ASTOR Aircraft 


The airborne TBO Prototype functionality was implemented within the ASTOR high-fidelity 
simulation, which is part of ATOS. An ASTOR station is a medium fidelity aircraft and avionics 
simulation with low fidelity single-pilot interfaces. An ASTOR contains a high-fidelity six degrees- 
of-freedom equations of motion aircraft model, autopilot and auto-throttle systems, software flight 
management computer, multifunction control display unit, model control panel, and electronic flight 
instrumentation system control panel as can be seen in Figure 12. The data communications system 
within the ATOS was modified to handle incoming DRNP re-route messages and outgoing ADS-C 
reports containing the EPP 4DT, as well as a 4DT representation of a UPRR request. The RPFMS 
within the ASTOR was modified to accept DRNP re-routes as well as A-IM clearances. The ATOS 
already had the ability to receive RTA messages. For this activity, one ASTOR station was utilized. 
The majority of the user interaction with ASTOR involved the Data Comm message page for 
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reviewing, auto-loading, and accepting or rejecting clearance messages, and the RPFMS functions 
which could be accessed through the Control Display Unit (CDU). 


Figure 12. ASTOR Simulation with the RPFMS CDU Shown at the Center of the Image. 
5.2.2 Traffic Aware Planner 


In an effort to achieve near-term benefits of ADS-B, NASA developed a Traffic Aware Strategic 
Aircrew Requests (TASAR) concept to enable user-optimal in-flight trajectory re-planning to 
increase the likelihood of ATC approval of re-planning requests. TAP, as can be seen in Figure 13, 
is the onboard software application that enables the TASAR concept. TAP processes surveillance 
data and other data from onboard sensors, databases, or data links to provide the flight crew with 
information to use to decide whether to make a trajectory change request and what request to make. 
This information can include conflict free trajectory changes recommended by TAP, conflict analysis 
of pilot entered trajectory changes, time and fuel savings, and other attributes. Current procedures 
are then used to issue and approve change requests through voice communication [Ballin and Wing, 
2012]. 


TAP was loosely integrated with the TBO Prototype as a method for generating UPRRs to 
demonstrate the early stages of trajectory negotiation. In this implementation, the re-route solution 
provided by TAP was manually entered into the ASTOR’s CDU to create a modified route in the 
RPFMS. This modified route could then be sent to the ground automation for review using the data 
link communications in the ASTOR simulation. Because the modified route was available within the 
RPFMS, the UPRR request was sent to the ground automation using the same 4DT format as an EPP 
message. The air traffic controller was able to review the re-route request and provide a CPDLC 
message approving or disapproving the request. 


5.2.3 Communications 
The communication between the ground automation tools and the aircraft automation followed the 
Baseline 2 Air Traffic Services Data Comm standards [RTCA, 2016a, 2016b]. Although the 


communication framework was simulated, each CPDLC or ADS-C message contained the data 
elements as specified in the published standards. 
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Figure 13. TAP Route Optimizing Application. 


6 Test Method 


6.1 


6.2 


SMEs participated in discussions of an Advanced 4DT operational concept that consisted of: a 
concept overview presentation, an interactive demonstration of the TBO Prototype, and a discussion 
session. The purpose of this activity was to obtain feedback on the operational concept that could be 
used in future concept and research development. 


Participants 


The participating SMEs for this research activity included five commercial airline pilots and five 
retired en route air traffic controllers. The pilots had an average of over 14,000 flight hours with 36 
years of flying experience. The en route controllers had an average of over 25 years of experience as 
active controllers. 


Procedure 


Each day of the Focus Group Evaluation included SME input from a pair of participants — one pilot 
and one controller. The SMEs were first given a one-hour briefing that described the Advanced 4DT 
concept, Prototype, and demonstration scenarios. Next, they were guided by researchers through the 
execution of four scenarios, each taking approximately fifteen minutes to complete. The participants 
filled out a short questionnaire (Appendix A) relevant to their operational position — pilot or controller 
— after the completion of each scenario. Finally, the SMEs participated in a discussion session for 
approximately two hours where they provided their input, recommendations, or observations with 
respect to a pre-determined set of operational, technological, and procedural questions (Appendix B) 
regarding the concept and the functionality that had been demonstrated during the scenarios. The 
participants provided input on these questions as well as other ad-hoc questions generated during the 
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6.3 


discussion. Participant comments were documented via audio recordings during both the scenario 
demonstrations and discussion session. 


In the demonstration scenarios, the controller SMEs were sometimes asked to conduct functions that 
would typically be considered inherently traffic flow management functions. The controllers were 
asked to provide their feedback about the allocation of these functions in an Advanced 4DT 
operational environment. 


Demonstration Scenarios 


Four operational scenarios were demonstrated to each pair of SME participants. The scenarios 
demonstrated proposed functionality of the Advanced 4DT concept that could be available in an 
enroute operational environment. The participants were guided in executing the objectives of each 
operational scenario using step-by-step instructions. The first three demonstration scenarios 
illustrated three stages of the same traffic flow through Cleveland Center (Figure 14). These 
scenarios included seven aircraft equipped as shown in Table 1. The fourth scenario focused on a 
traffic flow through Atlanta Center (Figure 15) and included a mixture of TBO-equipped and non- 
TBO-equipped aircraft. In each scenario, one of the traffic aircraft was an ASTOR with a RPFMS 
and a TAP route optimization tool that was operated by the pilot participant. The remaining aircraft 
were lower fidelity aircraft simulated within the TBO-TIGAR prototype tool and were monitored by 
the controller participant. In all scenarios, aircraft equipped with Data Comm were sharing 4DT 
information with the ground automation tools on a periodic basis (updated 4DT information was 
available every five minutes). 


Figure 14. Scenario 1, 2, and 3 Area of Interest. 


Table 1. Aircraft Equipage for Scenarios 1, 2, and 3. 


Aircraft | DRNP / Data Comm A-IM TAP RTA 
1 v v v 
2 v v 
3 v v v 
4 v v 
5 v 
6 v 
7 v 
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6.3.1 


Figure 15. Scenario 4 Area of Interest. 


Scenario 1 — Weather-Clear Dynamic Re-Routing 


Scenario 1 demonstrated the ability to generate dynamic re-routes to solve a weather conflict with a 
stream of aircraft (Figure 16). Weather blocked one of the airways through Cleveland Center and 
ground automation tools were used to generate DRNP and DRNAV re-routes to solve the weather 
conflict just prior to entering a flow-constrained area (FCA) boundary into New York Center. The 
re-routes were issued to each aircraft based on their equipage. The ASTOR aircraft received a DRNP 
re-route request via data link as well as an ADS-C request for 4DT information. The weather-clear 
dynamic routes that were generated in this scenario resulted in conflicts with other traffic streams, 
thereby requiring additional dynamic re-routing for those flights. The step-by-step actions used to 
execute Scenario 1 are listed in Table 2. 


NOTE: not to scale 


== DRNP re-route 
== DRNAV re-routes 


Figure 16. Weather-Clear Dynamic Re-Routing of Scenario 1. 
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Table 2. Step-By-Step Pilot and Controller Actions for Scenario 1. 


Step SME Action 
1 Controller _| Compute a DRNP re-route to resolve the weather conflict 
2 Controller | Compute a DRNAV re-route for non-TBO-equipped aircraft that closely 


follows the DRNP solution 

3 Controller | Send DRNAV clearances to candidate non-TBO-equipped aircraft 
4 Controller | Send DRNP clearances to candidate TBO-equipped aircraft 

p) Pilot Load the DRNP clearance into the RPFMS 

6 Pilot Verify the acceptability/feasibility of the DRNP re-route 

Zz 

8 

9 


Pilot Execute the DRNP re-route in the RPFMS 

Pilot Respond to ATC with WILCO 
Controller | Send ADS-C request for 4DT information to TBO-equipped aircraft * 
10 Pilot Load the ADS-C request into the RPFMS ” 
11 Controller | Compute a DRNAV re-route for aircraft impacted by newly- 
implemented DRNP and DRNAV re-routes (e.g., for traffic passing 
through DMACK in Figure 16). 
12 Controller | Send DRNAV clearances to the impacted flights 


6.3.2 Scenario 2 - Aircraft Specific Re-Routing and Electronic Negotiation 


Scenario 2 demonstrated early stages of trajectory negotiation in a TBO environment (Figure 17). 
The ASTOR aircraft had the ability to generate UPRR requests, using the TAP application, and to 
send those requests to ground automation via Data Comm. One such UPRR, as shown in Figure 17, 
was generated and sent by the pilot to the ground automation where the controller participant was 
able to review the request and accept it via Data Comm. The step-by-step actions used to execute 
Scenario 2 are listed in Table 3. 


NOTE: not to scale 


-—- 
-— 
oo" 
-— 
-— 


== DRNP re-route 
== DRNAV re-routes 
== User-pref. route 


Figure 17. User-Initiated Re-Route Request (Green) of Scenario 2. 


? These were manual steps in the TBO Prototype simply for the purposes of highlighting this data exchange process. 
These would be automated actions in a TBO environment with no user input required. 
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Table 3. Step-By-Step Pilot and Controller Actions for Scenario 2. 


Step SME Action 
1 Pilot Monitor TAP application for a time-saving and/or fuel-saving route 
optimization 
2 Pilot Manually enter TAP-provided re-route solution into the RPFMS CDU 
3 Pilot Send 4DT re-route request to ATC via Data Comm 
4 Controller | Review user-provided 4DT re-route request 
5 Controller _| Approve user-provided re-route request via CPDLC 
6 Pilot Execute the re-route in the RPFMS 
7 Pilot Respond to ATC with WILCO 
8 Controller | Send ADS-C request for 4DT information to the ASTOR aircraft ° 
9 Pilot Load the ADS-C request into the RPFMS ° 


6.3.3 Scenario 3 — Flow Management 


6.3.1 


Scenario 3 demonstrated the ability to apply different control strategies in meeting a metering 
schedule (Figure 18). A time-based scheduler provided scheduled times of arrival for aircraft 
crossing from Cleveland Center into New York Center. The controller participant used the ground 
automation tools to generate RTAs and A-IM clearances that were sent to aircraft after passing the 
scheduler’s freeze horizon. The step-by-step actions used to execute Scenario 3 are listed in Table 4. 


NOTE: not to scale (C) pasar ~ 
-—---"™ 


== DRNP re-route 
== DRNAV re-routes 
== User-pref. route 
@ RTA 


Figure 18. Time-Based Metering Control of Scenario 3. 
Scenario 4 — Dynamic Re-Routing, On-Demand Metering, and Flow Management 


Scenario 4 demonstrated a somewhat different approach to the same capabilities of scenarios 1 and 3 
and added the ability to generate an on-demand, time-based scheduler for flow control through the 
dynamically-generated re-routes (Figure 19). In this scenario, weather blocked a busy airway through 
Atlanta Center. The ground automation was used to identify the aircraft that were projected to be 
impacted by the weather and to generate DRNP and DRNAV re-routes that leveraged a gap in that 
weather. The ground automation was then used to assign each aircraft to the available re-routes based 
on equipage. An on-demand metering scheduler was created to manage the flow at the exit to the 


3 These were manual steps in the TBO Prototype simply for the purposes of highlighting this data exchange process. 
These would be automated actions in a TBO environment with no user input required. 
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dynamic re-routes and was used to implement schedule control strategies such as RTA and A-IM 
clearances. The step-by-step actions used to execute Scenario 4 are listed in Table 5. 


Table 4. Step-By-Step Pilot and Controller Actions for Scenario 3. 


Step SME Action 
1 Controller | Generate and send an RTA clearance to the ASTOR aircraft via Data 
Comm 
2 Pilot Load the RTA clearance into the RPFMS and verify the RTA feasibility 
3 Pilot Execute the RTA clearance in the RPFMS 
4 Pilot Respond to ATC with WILCO 
) Controller | Send ADS-C request for 4DT information to the ASTOR aircraft * 
6 Pilot Load the ADS-C request into the RPFMS 4 
7 Controller | Generate and send an RTA clearance via Data Comm to the second 


aircraft in the sequence 
8 Controller | Send ADS-C request for 4DT information to the second aircraft in the 


sequence * 

9 Controller | Generate and send an A-IM clearance for the third aircraft in the 
sequence, with the target traffic being the second aircraft in the 
sequence 

10 Controller | Send ADS-C request for 4DT information to the third aircraft in the 
sequence * 

11 Controller | Issue a delay-absorbing speed instruction to the fourth aircraft in the 
sequence 

NOTE: not to scale wx %~ 


On-demand 
Metering Boundary 


== DRNP re-route 
== DRNAV re-route 


Figure 19. Dynamic Re-Routes and On-Demand Metering of Scenario 4. 


4 These were manual steps in the TBO Prototype simply for the purposes of highlighting this data exchange process. 
These would be automated actions in a TBO environment with no user input required. 
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Table 5. Step-By-Step Pilot and Controller Actions for Scenario 4. 


Step SME Action 
1 Controller | Inspect projected weather conflict list 
2 Controller | Compute a DRNP re-route to resolve the weather conflict through a gap 


in the weather 
3 Controller | Compute a DRNAV re-route for non-TBO-equipped aircraft that closely 
follows the DRNP solution through the gap in the weather 


4 Controller | Create an on-demand metering scheduler at the end of the DRNP and 
DRNAYV re-routes 
5 Controller | Use the weather conflict list to identify conflict priority and candidate 


re-route options for each flight 
6 Controller | Sequentially issue DRNAV and DRNP re-routes to candidate aircraft 
based on TBO- or non-TBO-equipage 


7 Pilot Load the DRNP clearance into the RPFMS 

8 Pilot Verify the acceptability/feasibility of the DRNP re-route 
9 Pilot Execute the DRNP re-route in the RPFMS 

10 Pilot Respond to ATC with WILCO 


11 Controller | Send ADS-C request for 4DT information to TBO-equipped aircraft ° 
12 Pilot Load the ADS-C request into the RPFMS ° 

13 Controller | Generate and issue RTA or A-IM clearances to aircraft using on the on- 

demand metering schedule 


14 Pilot Load the RTA clearance into the RPFMS and verify the RTA feasibility 
15 Pilot Execute the RTA clearance in the RPFMS 
16 Pilot Respond to ATC with WILCO 
17 | Controller | Send ADS-C request for 4DT information to the ASTOR aircraft ° 
18 Pilot Load the ADS-C request into the RPFMS ° 
7 Results 


The SMEs participated in the interactive demonstrations and provided feedback in the form of brief 
post-scenario questionnaires as well as researcher-guided debrief discussion sessions where the 
participants discussed their impressions and recommendations. The results from these post-scenario 
activities are presented in the following sections. 


7.1. Scenario Qualitative Results 


At the end of each scenario, the SMEs completed a post-scenario questionnaire (Appendix A). The 
post-scenario questions were presented as statements and the SMEs were asked to rate their 
agreement with those statements on a scale of 1 (strongly disagree) to 7 (strongly agree). The 
controller and pilot SMEs provided ratings to statements regarding each of their respective domains, 
i.e., with respect to ground-based traffic control and management for controllers and with respect to 
flight deck operations for the pilot. This section provides the SME questionnaire ratings. 


° These were manual steps in the TBO Prototype simply for the purposes of highlighting this data exchange process. 
These would be automated actions in a TBO environment with no user input required. 
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7.1.1 


Controller Post-Scenario Questionnaire Results 


The mean ratings for the post-scenario questions for the five controller SMEs are presented in Table 
6. The number of responses for each question and rating are shown in Figure 20 through Figure 25. 
All controllers agreed or strongly agreed that they fully understood what was going on during the 
scenario (Question A) (Figure 20). All of the controllers agreed or strongly agreed that it was easy 
to understand what was going on during the scenario in terms of mental effort required (Question B) 
(Figure 21). All controllers agreed or strongly agreed that they would use the operational capability 
encountered in the scenario to re-route aircraft (Question C) (Figure 22). All controllers, except for 
one, did not feel that the operational capabilities encountered would hinder their duties (Question D). 
One controller slightly agreed that the operation capabilities encountered during all scenarios would 
hinder his duties (Figure 23)°. All controllers agreed that they could use the operational capabilities 
encountered to manage traffic and still maintain situation awareness (Question E) (Figure 24). All 
controllers, except for one, agreed or strongly agreed that they could use the operational capabilities 
encountered to manage traffic and maintain low mental workload (Question F). One controller was 
neutral in rating the ability to use the operational capabilities encountered in Scenario 3 to manage 
traffic and maintain low mental workload (Figure 25). 


Table 6. Controller Post-Scenario Questionnaire Ratings. 


Question Scenario 1 Scenario 2 | Scenario3 | Scenario 4 
(mean, SD) | (mean, SD) (mean, SD) | (mean, SD) 
A. I fully understood what was going on 6.4, 0.5 6.6, 0.5 6.6, 0.5 6.6, 0.5 


during this scenario. 


B. It was easy to understand what was going 6.6, 0.5 6.6, 0.5 6.6, 0.5 6.6, 0.5 
on during this scenario (in terms of mental 
effort required). 


C. I would use this operational capability 6.8, 0.4 6.8, 0.4 6.6, 0.5 6.6, 0.5 
(DRNP, DRNAV, UPRR, RTA, A-IM) to 
re-route aircraft. 


D. This operational capability would hinder 2.6, 1.5 2.4, 1.5 2.4, 1.5 2.6, 1.5 
my duties. 
E. I could use this operational capability to 6.6, 0.5 6.6, 0.5 6.2, 0.8 6.4, 0.5 


manage traffic and still maintain my 
situation awareness. 


F. I could use this operational capability to 6.2, 0.4 6.4, 0.5 6.2, 1.3 6.4, 0.5 
manage traffic and maintain low mental 
workload. 


SD = Standard Deviation 


5 No reasoning was given as to why this controller felt that the operation capabilities encountered during all 
scenarios would hinder his duties. 
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| fully understood what was going on during this scenario. 
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Figure 20. Controller Responses for Post-Run Question A. 


It was easy to understand what was going on during this 
scenario (in terms of mental effort required). 
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Figure 21. Controller Responses for Post-Run Question B. 


| would use this operational capability (DRNP, DRNAV, UPRR, 
RTA, A-IM) to re-route aircraft. 
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Figure 22. Controller Responses for Post-Run Question C. 


25 


This operational capability would hinder my duties. 
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Figure 23. Controller Responses for Post-Run Question D. 


| could use this operational capability to manage traffic and 
still maintain my situation awareness. 
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Figure 24. Controller Responses for Post-Run Question E. 


| could use this operational capability to manage traffic and 
maintain low mental workload. 
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Figure 25. Controller Responses for Post-Run Question F. 
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Additionally, controllers were asked which controller position(s) should handle the operational 
capabilities encountered during each scenario (Question G). The summarized controller responses 
to Question G are presented in Table 7. In general, the controllers felt that the traffic management 
unit (TMU) or traffic management coordinator (TMC) should be responsible for generating the 
operational constraints demonstrated by each of the scenarios (dynamic re-routes, UPRR initial 
approval, time constraints, spacing constraints), particularly when the traffic load is heavy, while 
ATC should be responsible for the implementation of those constraints. Some controllers felt that 
the D-side controller, or data controller, could also be responsible but the R-side controller, or radar 
controller, should only handle traffic re-routes if the traffic loads were normal. The R-side controller 
uses radar information as the primary method for separating aircraft and is in direct communication 
with the aircraft. The D-side controller is the assistant to the R-side controller and is responsible for 
sequencing flight strips, providing non-radar separation under certain circumstances, and assisting 
the R-side controller with coordination with other sectors. 


Table 7. Controller Responses to Post-Scenario Question G. 


Scenario Controller Responses 
1 


TMU should be responsible if scale is large. 

TMC would generate routes. ATC would issue commands to aircraft. 

TMU or D-side controllers responsible with busy traffic. 

TMU. 

D-side controller should be responsible. R-side controller could be responsible under 

normal traffic loads but not with busy traffic because he would not be focusing on the 

scope (traffic). 

2 e TMU should be responsible because reroute could impact several sectors. 

e TMC should receive UPRR requests and relay them to ATC to execute. 

e It depends on the traffic load. TMU should be responsible when real busy or slow, D- 
side controller when busy, and R-side controller when not busy. 

e __R-side controller should be responsible with TMU approval. 

e TMU or D-side controller and automation should be responsible; R-side controller with 

light workload. 

TMU and sector that is actively controlling aircraft should be responsible. 

TMU should generate routes and times. ATC would execute commands. 

TMU would be better to issue time-based management times. 

R-side controller should be responsible with TMU direction. 

TMU or D-side controller and automation should be responsible; R-side controller when 

not busy. 

MU. 

MC would generate route. ATC would execute commands. 

e It depends on the traffic load. As a controller with weather in your sector, you are the 
best one for re-routes (knowing where aircraft are deviating) but the TMU or D-side 
controller might be better entity to input data. 

e Routes should be created by the TMU and implemented by the R-side controller. 

e TMU or D-side controller and automation should be responsible. The R-side controller 

cannot be doing many extra tasks when busy. 


7.1.2. Pilot Post-Scenario Questionnaire Results 


The mean ratings for the post-scenario questions for the five pilot SMEs are presented in Table 8. 
The number of responses for each question and rating are shown in Figure 26 through Figure 31. All 
pilots, except for one, agreed or strongly agreed that all the operational capabilities encountered 
would be useful to them for performing TBO (Question A). One pilot was neutral in rating the RTA 
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capability as being useful for performing TBO (Figure 26). All of the pilots did not feel that the 
operational capabilities encountered would hinder their duties (Question B) (Figure 27). All pilots 
agreed that they could perform the operations encountered and still maintain situation awareness 
(Question C) (Figure 28), maintain low mental workload (Question D) (Figure 29), and maintain low 
physical workload (Question E) (Figure 30). The pilots also agreed that the user interface was 
effective for performing the operation encountered (DRNP, UPRR, and RTA) (Question F) (Figure 
31). 


Table 8. Pilot Post-Scenario Questionnaire Ratings. 


Question Scenario 1 | Scenario 2 | Scenario3 | Scenario 4 
(mean, SD) | (mean, SD) | (mean, SD) | (mean, SD) 

A. This operational capability will be useful to 6.4, 0.5 6.0, 0.0 6.0, 1.2 6.0, 0.0 
me for performing trajectory-based 
operations. 

B. This operational capability would hinder 2.0, 0.7 2.2, 0.4 1.8, 0.4 2.0, 0.0 
my duties. 

C. Icould perform this operations (DRNP, 6.4, 0.5 5.8, 0.4 6.4, 0.5 6.0, 0.0 
UPRR, RTA) and maintain my situation 
awareness. 

D. Icould perform this operation while 6.4, 0.5 5.6, 0.5 6.0, 0.7 6.0, 0.0 
maintaining low mental workload. 

E. Icould perform this operation while 6.6, 0.5 5.8, 0.8 6.4, 0.5 6.4, 0.5 
maintaining low physical workload. 

F. The user interface was effective for 6.4, 0.5 6.2, 0.4 6.2, 0.4 6.2, 0.8 
performing this operation (DRNP, UPRR, 
RTA). 


This operational capability will be useful to me for 
performing trajectory-based operations. 
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Figure 26. Pilot Responses for Post-Run Question A. 
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This operational capability would hinder my duties. 
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Figure 27. Pilot Responses for Post-Run Question B. 


| could perform this operation (DRNP, UPRR, RTA) and 
maintain my situation awareness. 
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Figure 28. Pilot Responses for Post-Run Question C. 
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Figure 29. Pilot Responses for Post-Run Question D. 
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7.2.1 


| could perform this operation while maintaining low physical 
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Figure 30. Pilot Responses for Post-Run Question E. 


The user interface was effective for performing this 
operations (DRNP, UPRR, RTA). 
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Figure 31. Pilot Responses for Post-Run Question F. 
Discussion Session Summary 


The SMEs participated in a researcher-guided debrief and discussion session where they provided 
their input, recommendations, or observations with respect to a pre-determined set of operational, 
technological, and procedural questions (Appendix B) regarding the concept and the functionality 
that had been demonstrated during the scenarios. Audio recordings were gathered and transcribed 
for each discussion session. A summary of the most relevant input is presented according to topic 
and question. 


TBO Operational Discussion 
Both the controller and pilot SME were asked the questions below. The bulleted responses represent 


a synopsis of the complete response provided by the participants to each question as summarized by 
the authors. 
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From your perspective, what are the benefits/impacts of trajectory-based operations (TBO)? 


Benefits from the controller’s perspective: 

e The scale of the system demonstrated was large enough to see traffic flows in nearby Centers 
which must be considered when re-routing traffic. 

e Defined routings around the weather. 

e More aircraft could probably be worked with this system in place. 

e More organized, consistent flow of traffic where it is clear to both the controller and pilot what the 
aircraft is doing, instead of, for instance, vectoring aircraft. 

e Fuel and time savings. 

e Less chaos and more confidence in spacing available around weather. 

e CPDLC eliminates issues due to language barriers and frequency problems due to sunspots, 
equipment failures, noisy cockpits, etc. 

e Giving one clearance for a re-route is preferred over the ambiguity that is inherent when vectoring 
aircraft. 


Impacts from the controller’s perspective: 
e Less workload because of reduced communications about problems and questions. 
e There could be problems if the system is not taking into account opposite direction traffic that may 
be trying to go around the same weather cell. 


Benefits from the pilot’s perspective: 

e Receiving clearances via CPDLC enables receipt of a very clearly defined clearance that can be 
reviewed on the FMC and navigation display before executing which eliminates ambiguity and is 
more expeditious. 

e Reduced communications and pilot workload when using CPDLC. 

e Removing disparity encountered between pilot and controller when vectoring aircraft. 


Impacts from the pilot’s perspective: 

e Improve the operation. 

e If aconversation is needed with ATC, it would be more cumbersome to use CDPLC free text than 
having a conversation over the radio. 

e  =There will be a disadvantage in a mixed equipage environment where some aircraft are equipped 
with CPDLC and some are not and all aircraft are not communicating in the same manner. 

e Not hearing the ‘party-line’ communication (hearing other aircraft’s communications) when using 
CPDLC to anticipate situations, such as re-routes and turbulence. 


Will TBO help you in performing your job? Why? 


Controller responses: 

e Perhaps TBO will allow for reduced spacing when re-routing around weather or other atmospheric 
events. 

e With TBO, most of the route changes will be generated through the TMC and given to the 
controller to issue. This will make the controller’s job simpler because of the defined nature of the 
routes. 

e CPDLC will improve communication. 

e TBO will produce a more uniform flow of traffic which will eliminate the need to monitor traffic 
individually that are taking different routes around weather. 

e TBO will result in more order which will give the controller more confidence in re-routing the 
traffic closer together because the exact route will be known. 
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Pilot responses: 


Yes. TBO will allow the pilot to keep the aircraft in the highest level of automation, 
LNAV/VNAV mode. 

Getting a re-route clearance that contains a full route instead of being vectored around the weather 
would be advantageous provided the weather that is shown in the cockpit is valid. Current radars 
are only accurate to about 80 miles out. As cockpit technology advances, down-range weather 
may be available to the pilots which will provide a situational awareness benefit. 

TBO will give the pilot the ability to have a better understanding of the ‘big picture’ by obtaining 
information from additional resources. For example, if an RTA is provided for when the arrival 
gate will be available, speed can be adjusted to avoid holding and burning fuel. 

TBO will make it easier for the pilot to understand where he is going and what he needs to do. 
Sometimes the pilot may not agree with the clearance but that is where negotiation comes into 
play. 

Pilots that are very conservative about weather avoidance today may come to accept TBO re- 
routes that are based on weather and real-time information if they were confident that the re-routes 
provided a safe weather buffer. 


Do you feel that TBO will increase, decrease, or otherwise change your workload? If so, in what 


way? 


Controller responses: 


Decrease workload because CPDLC will reduce communications. 

TBO may increase workload, at least initially; there will be a learning curve. 

Overall, TBO would decrease workload. 

Increase workload, just from inputs alone, particularly if the R-Side controller is trying to make 
the inputs when traffic is busy. 


Pilot responses: 


Decrease workload as long as things stay in a steady state. 

TBO is just utilizing a different tool and would cause no change in workload. 

Decrease workload after initial learning curve. How to re-route to deviate around weather is 
mostly up to the pilot currently. If ATC were to give the pilot options to avoid weather, the pilot 
would just have to accept one, which gives the pilot one less thing to manage. 

Decrease workload, but there are ways to improve the system demonstrated today. 

Decrease workload due to CPDLC communications making it easier to receive, load, accept, and 
execute clearances. 


What challenges do you see in implementing a TBO concept? Please comment on issues such as 
mixed equipage environment, etc. 


Controller responses: 


The government is slow in implementing new equipment. 

People are generally set in their ways and resistant to change. Making controllers aware of what 
new systems can do to improve the system would be beneficial. [2 participants] 

There will be issues with a mixed equipage environment but they will be more manageable 
because the controller will know where each aircraft will be located. 

Education is important; training and change in mindset. 

Mixed equipage should not be a problem as long as the controller is aware of each aircraft’s 
equipage ahead of time. 

Younger people are used to using technology but older individuals have a different mind-set due 
to years of training. 
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Pilot responses: 


Even though aircraft may be equipped with the same equipment, options are available for purchase 
so the same equipment may not have the same functionality. 

TBO is just another way of doing the same thing in a more automated fashion with less verbal 
communication, so no challenges. 

Mixed equipage is going to be the biggest growing pain in trying to get everyone to do things in 
the same manner. 

Pilot training is mostly computer-based with little classroom and simulator training. This can be 
problematic because distractions can reduce the effectiveness of computer-based training. 
Getting the airlines to purchase the necessary equipment. It is important that equipment is 
software-based so upgrades can occur without making hardware changes. 

Keeping all players up to speed on system software changes and features. 


Do you prefer segregated airspace in which equipped and unequipped aircraft do not operation 
together or do you believe there is a role for integrated airspace in which equipped and unequipped 
aircraft do operate together? 


All controller and pilot SMEs felt that equipped and unequipped aircraft could operate together. 
Some additional comments were that the unequipped aircraft would be at a disadvantage and 
integrated operations would depend on how busy and congested the operational area was. 


Do you have any safety concerns or issues with the TBO concept that was presented to you today? 
If so, what are they? 


Controller responses: 


No safety concerns. However, the party responsible for re-routing traffic must be aware of traffic 
in nearby sectors or areas where the traffic is being re-routed. 

The only concern is the actual weather system itself and how to define it in a finite manner and 
project the weather’s path. 

The concept would be safer in a lot of ways, particularly with the CPDLC communications. 

No safety concerns. The TBO concept provides a way to be more creative with the airspace. 

No safety concerns, but would need tools to ensure that a mental picture of the location of all 
aircraft is maintained since aircraft can be on different routes. 


Pilot responses: 


No safety concerns. However, it should be made clear that the weather presentation shows the 
location of the actual weather and also indicates a buffer around the weather, e.g., 20 miles, so it is 
obvious that the route is clear of the weather. 

The situation is only as safe as the equipment, so as long as the equipment is working there are no 
issues. There must be some type of recourse in the event that messages are not being transmitted; 
a back-up plan which reverts to lower level automation. 

No safety concerns. The ultimate conflict resolution is the Traffic Collision Avoidance System 
which is running in the background. 
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How do you think these new TBO procedures should be integrated with current operational 
procedures? 


Controller responses: 

e The TMU would be designing the re-routes because it encompasses several sectors. 

e The Command Center and the TMCs are going to be the ultimate approving authority for 
negotiation and implementation of routes. The controllers will be issuing the clearances and 
monitoring the operations. 

e Opposite direction and perpendicular traffic must be taken into consideration when re-routing 
aircraft because they will want to deviate in the same direction as the oncoming traffic. 

e Acchain of command must be established. The TMU will likely create the re-routes which the 
Command Center must endorse. The controller will then be given the re-routes either by the TMU 
or the Command Center. 

e TBO procedures should be integrated slowly. Start with a small test base to prove the procedures 
work. This will convince others of the benefits. 


Pilot responses: 
e New procedures must be trained to make sure they are understood. 
e Start with a test base to work out any issues then implement over a period of time. 


What do you think the humans’ role should be in trajectory negotiation and changes? (Note: Does 
management (TMC) setup negotiation strategy and DST prompts controller and pilot?) 


Controller responses: 

e The TMC and Command Center will do most of the negotiations. The controller will have very 
little input other than providing information on what the aircraft are doing as the weather becomes 
an impact. The TMC and command center will also develop routing solutions and the controller 
will pass the information to the aircraft. 

e Trajectory negotiation and changes can be done by automation as long as humans set the 
parameters. There is always the option to override it. 

e A lot of negotiations will occur between the flight operations center and the Command Center, 
outside of the operational environment. This is done today. 

e Today, the TMU decides on the re-routes and the controller doesn’t really have input into it. Even 
if the controller could input constraints and have the automation negotiate and determine the re- 
routes, the TMU would still have to be involved. 


Pilot responses: 
e The human is the final authority. 
e Automation can make the plan but as conditions change, the human has to get involved and 
determine if there is another safer course of action to follow. 


How do you anticipate the airlines will attempt to game the system? Do the airlines do this today? 


Controller responses: 

e It’s human nature to try to take advantage of the system. 

e If an airline tried to game the system by not buying equipment that allowed them to conduct 
certain maneuvers, they will pay for it in other ways, e.g., burning more fuel because they are not 
equipped to fly certain Standard Terminal Arrival Routes. 

e [donot see how the system demonstrated today could be manipulated by the users. 
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Pilot responses: 


An airline is not going to develop a policy to try to get in the front of a queue, but a pilot may very 
well do what they want to do. 

Of course. The airline may try to define preferences or strategies to achieve the shortest route, but 
most gaming may be offset by the other constraints in the system (one example is gate availability 
if the aircraft arrives too early). 

Anytime there is a system there will be opportunities for people to exploit it. There is a perception 
that the predominant carrier at an airport gets preferential treatment. People must have an integrity 
to make sure that doesn’t happen, especially if safety is a factor. 

Airlines will attempt to game the system through their network operations center (dispatchers) if 
they can get operations flowing when things start to bottleneck. 

There will probably be more problems at the cockpit level than at the airline level. 

Airlines are game for anything that will save them money. 

An example, airline dispatchers were creating higher speeds to try to keep pilots legal when 
getting close to the duty time limit. A system that is time and speed based would keep this type of 
thing from happening. 


The following questions were geared toward the controller SME: 


How would you monitor pilot conformance to RTAs? To IM clearances? 


RTA monitoring: 


Just like we do today, just watch them. The radar scope includes projections that will indicate if 
aircraft are not conforming. Controllers are also provided with information informing them if the 
aircraft are maintaining speed. 

Monitoring RTAs would basically be like monitoring a crossing restriction. Controllers would 
have to adjust speeds or vector aircraft to ensure compliance. Restrictions are issued to the aircraft 
and controllers count on pilots to comply. 

I would monitor visually. It would be helpful to have information in the data block that shows 
minutes late (plus number) or minutes early (minus number). Now time can be monitored to a 
metering fix. The aircraft is considered on time if it is within plus 10 or minus 1 minutes. 

For monitoring RTAs using current equipment, it would be a manual monitoring process where I 
use the range bearing feature button, click on the data block, click on the fix and a time to that fix 
is provided. It would be advantageous to have a delay countdown timer to the RTA. 

Controllers currently monitor aircraft continuously and through experience know if aircraft are on 
time. I would also monitor speed to determine if there are any big changes. 


IM monitoring: 


IM is different in that the aircraft are responsible to maintain spacing but the controller will still be 
responsible for separation. Ideally the controller would monitor closely until the aircraft report 
they are paired. When IM is initially implemented, controllers will likely monitor the operation 
closely, but years down the road once more experience is acquired or if regulations are changed 
relieving controllers of the separation responsibility that may not be the case. 

For monitoring IM clearances, information in the data block regarding time to cross a fix would be 
useful. 

There are vector lines on the data block that correspond to one minute of flying time. Displaying 
two lines is equivalent to two minutes, etc. That can be used to establish the spacing, then if the 
speed stays constant they will maintain that spacing. 

Speed would be used to monitor IM conformance but it is up to the pilots to maintain spacing. 
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How much time would you have to evaluate or generate proposed dynamic routes? Under normal 
conditions? Under severe weather conditions? 


The TMU would generate re-routes prior to reaching the weather. Controllers are busy when 
trying to move aircraft coming up on weather. The optimal time to re-route the traffic would be 
before they encounter the weather. 

The controller has no time. The TMC and command center evaluate the weather continuously. 
Under normal conditions the controller has time. With severe weather, the TMU or D-side 
controller would have to do the re-routes, but the TMU would probably be best. 

Under standard traffic loads, a controller would have anywhere from 20 to 40 seconds to build a 
re-route without impacts. Severe weather develops and re-routing is generally done ahead of time. 
Under normal conditions, the controller would have time but not under weather conditions. 
Coordination doubles under severe weather. The D-side controller could do the re-routing but the 
TMU would have to be involved. The controller (R-side) would have time to generate re-routes to 
avoid conflicts or for path stretching. 


When would you want to be involved in developing dynamic re-routing? What would you want the 
role of the supervisor and TMU to be? 


The sector controller gives the first notification that there is an issue. The controller notifies the 
area supervisor who notifies the TMU who works with the command center for developing re- 
routes. 

It would be beneficial for the TMC to consult with the controllers from the affected areas prior to 
developing the re-route plan because the controllers normally have better insight on the effects on 
their area. 

The TMU should develop the re-route plan. The controller should be involved when the plan is 
not working or when pop-up weather occurs in their sector. 

The controller should have input in developing dynamic re-routing because they may have 
information that the Command Center or the TMU have overlooked or have not considered. The 
controller should have the opportunity to agree to the re-routing if it impacts operations in their 
sector directly. 

When traffic begins deviating, the controller informs their supervisor who in turn informs flow 
control and then re-routes are developed. Re-routes are not issued many times until traffic have to 
be put on hold. It would be nice for the controller to have input into re-routes that affect their 
sector. 


How would you review a proposed re-route before issuing it to aircraft? What information would 
you need? 


For the en route controller to issue a route it must be for a short duration, something that can be 
negotiated with the adjacent sector. 

With DSTs being used, there is a concern if the TMU DSTs are sending the re-routes directly to 
the aircraft and the controller is unaware of the re-route. 

If weather is close or pup-up weather, the controller will work with the pilot to come up with an 
initial re-route flow and then traffic management will review. If the weather is forecasted, the 
controller will have very little input into the re-route flow until the dynamic changes. 

The ability to view the planned re-route overlaid on the sector map would be useful. [2 
participants] 

A temporary display of the proposed re-route and elements that have been considered in 
developing the re-route would be useful. 


The following questions were focused toward the pilot SME: 


How much time would you have to devote to re-plan your route when you’re in cruise flight? 


All pilots indicated that there is plenty of time during cruise flight to re-plan a route. 
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Do you feel that your dispatchers would be supportive of you re-planning the route while en route? 


All pilots felt that their dispatchers would not have any issues with the pilot re-planning the route. 
The critical issue is whether the re-route impacts fuel supply. 


What constraints may your airline impose to limit the number of re-routes that are generated by 
the flight deck (i.e., need dispatch concurrence for re-routes that deviate more than 100 nautical 
miles from the original route)? 


Constraints to limit the number of re-routes would not be a consideration for my airline. 
Dispatch must be notified when deviations of 100 miles or more are made so the legality side can 
be assessed. Airlines cannot limit the number of re-routes. 

Dispatch must be notified when deviations of 100 miles or more are made. The airline prefers 
following the plan unless it needs to be changed. A high frequency of re-routes increases the 
dispatcher workload. 

In the future, the dispatcher may be made aware of any re-routing automatically through 
automation so the re-routing can be assessed. 

Pilots are obligated to keep the dispatchers in the loop but they are also obligated to keep the 
airplane safe based on the current conditions. 


Do you think that these constraints may be relaxed as route re-planning from the flight deck 
becomes more normal? 


Just like anything new, as people gain more familiarity, the constraints can be reduced. 

Possibly. If route re-planning from the fight deck becomes more normal and the technology is 
there to support it, dispatch would not try to constrain it. 

Whenever we are re-routed, as a courtesy, we notify dispatch of the re-route via ACARS. Ifa re- 
route is given by ATC, the pilot reviews it by typing in the FMC to determine if there is enough 
fuel for the re-route. Once the re-route is verified, the pilot accepts the clearance and then notifies 
dispatch. However, if ATC offers a direct clearance as a convenience tool, the pilot would discuss 
it with dispatch before it could be accepted. 


When is it beneficial to do UPRR? How much time/fuel needs to be saved? 


Many factors determine when it is beneficial to request UPRR, such as passenger’s connecting 
flights and amount of fuel onboard. 

Five minutes and 500 pounds of fuel would be a trigger. When an ETA is exceeded by 5 minutes 
that data must be entered into the system so the flight arrival information is updated. 

Saving 200 pounds of fuel over a long period of time, over a number of flights is significant. 

One hundred to 150 pounds of fuel would probably be enough savings to consider UPRR. 

One to two minutes and 100 pounds of fuel would be worth it. 
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7.2.2. TBO Technological Discussion 


Both the controller and pilot SME were asked the following questions: 


What additional automation/tool capabilities do you think you would need to successfully conduct 
operations that you saw during this demonstration? 


Controller responses: 


Currently the controller can create a flight plan for an individual aircraft on the EDST [En Route 
Decision Support Tools], but cannot set it up for a stream of aircraft. 

If the pilot requests a specific re-route around weather and it is a valid request, the controller can 
just say ‘cleared as requested’ without having to give a full clearance with waypoints included. 
A conflict probe applied to the UPRR prior to being sent to the controller for acceptance. 

The ability to display where the re-route will reconnect with the route. 

Color coded call signs on the EDST to show whether aircraft are TBO equipped or not would be 
useful. 

Some type of indication, such as color, to make the controller aware that a UPRR request has been 
received. 

The ability to view the plan track for different aircraft. 


Pilot responses: 


On the 787 navigation display, the pilot can define a route around weather that consists of 
latitude/longitude points. It would be beneficial for the controller to be made aware of this route 
that the pilot is following. 

It is not good practice to leave an open execute light. A way around that would be for the pilot to 
enter and request the re-route, then delete the route from the FMC. The controller would then 
send the full clearance to the aircraft that would be loaded into the FMC. Another method could be 
sending the route request to ATC directly from the TAP tool. 


What subset of TBO functionality would produce the greatest benefit with minimal equipage 
requirements? 


Controller responses: 


RTAs because regardless of aircraft equipage, the aircraft could cross a fix at a certain time. 
Re-route options to choose from that have the latitude/longitudes defined that can just be sent to 
the aircraft. 

Creation and distribution of temporary routes; the ability for routes created by the TMU to be 
displayed to the controller by the touch of a button. 

The ability to receive UPRR requests via CPDLC will reduce verbiage and make the controller 
aware of the exact route the aircraft is going to take around weather. 


Pilot responses: 


CPDLC capability. [3 participants] 
The ability to view re-route options. 
DRNP. 


38 


The following questions were geared toward the controller SME: 


Should an air traffic controller have the ability to visualize an aircraft’s planned 4DT? If so, by 
what method — 3D path, separate vertical/horizontal profiles, other? If not, why? 


Yes, it would be nice to display the current flight plan as well as the planned route. 

It would be beneficial to display the turn geometry. 

No, there are too many aircraft and the controller has enough to monitor than to be concerned with 
the 4DT of each aircraft. 

The en route controller does not really need to view the vertical profile trajectory but it would be 
nice to view it. 

Seeing the vertical profile would be nice but it would probably not be used to separate aircraft. 
The vertical profile would only be useful in transition airspace but not en route. 

Viewing the 4DT would be too much clutter. However, it may be nice to be able to view it when 
desired with a button press and have the information highlighted in some manner, such as with 
color. 


Would you trust using an airborne generated trajectory for scheduling and sequencing? 


All controller SMEs indicated they would trust using an airborne generated trajectory; however, 
they would verify the trajectory and monitor conformance. 


What information will you need to enable you to plan and manage aircraft 4DTs? 


In planning I generally take into consideration: route geometry, current altitude, current speed, 
requirements for climbs/descents, and aircraft type. This is useful for building a mental picture of 
the pending trajectory change. 

ADT information would be useful to traffic management but it is too much information for a 
controller. 

Knowing how aircraft are equipped so the controller can determine what an aircraft is capable of 
and if clearances can be automated or transmitted via voice. [2 participants] 


Do you have any specific ideas/suggestions for a user interface? 


Two boxes side by side with the velocity vector and heading and also two boxes side by side with 
ground speed and altitude. 

Have pilot requests displayed in a color to bring it to the controller’s attention. Color can also be 
used to indicate when a clearance is accepted (green) or rejected (red). 

The ability to move the data blocks associated with each aircraft and a timeline display. 

The ability to click, scroll, and draw routes. 

Color coded call signs on the EDST to indicate equipage levels. 


What level of detail would you like to know about an aircraft’s level of equipage? 


Perhaps a right mouse click that brings up a menu that which equipment qualifiers qualify for the 
different operations. 

A controller would need to be notified of the aircraft’s level of equipage by an equipment suffix 
added to the flight plan. [2 participants] 

I would like to know if an aircraft is data link and ADS-B equipped and RTA capable. 
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The following questions were focused toward the pilot SME: 


Have you ever conducted an RTA operations? If so, have you used the time component of the 


4DT? 
e 


Yes, I have received an RTA clearance in international airspace. 

Yes, I have received a clearance to ‘cross no earlier than’ but not in domestic airspace. The RTA 
information was manually typed into the FMS. 

Three pilots had not ever conducted RTA operations. 


What information will you need to enable you to conform to a 4DT? 


The controller should be doing the conformance monitoring. 

The information given in the demonstration today would be sufficient. 

RTAs can be monitored on the navigation display. After pressing a data button on the Electronic 
Flight Instrument System control panel, the time that the aircraft will cross the waypoints is 
displayed next to each waypoint. RTAs can also be monitored in the FMC on the Progress page 
down to the second. 

Having the seconds early or late displayed on the data tag, possibly in a different color, would be 
enough information. 

The RTA Progress page on the FMC would have enough information to follow an RTA. It would 
also be nice to receive an FMC message when out of compliance. Having multiple sources of 
information is beneficial. 


Do you have any specific ideas/suggestions for modifications to the user interface? 


Do not make a UPRR request by leaving an un-executed modified route in the FMC for an 
extended period of time (an open Execute light). [3 participants] 

A way to handle the UPRR request is to enter the route into the second route option (Mod route 2), 
if available. That way the route is saved and can be executed once the clearance is sent by the 
controller. 

Develop a procedure for loading and accepting data link messages; load then accept or accept then 
load. 

The ability to create a UPRR by touching the screen and dragging the route to the desired location. 


7.2.3 TBO Procedural Discussion 


Both the controller and pilot SME were asked the following question: 


Assuming multiple route options meet the constraints, how many options would you want to see 
displayed? Would you like the ability to sort based on user-preferred business models? 


Controller responses: 


It depends on the scale being viewed on the scope. If viewing a larger scale, three options would 
be nice. If viewing a smaller scale (two or three sectors), anything more than two options would 
be clutter. 

No more than three options. [2 participants] 

One option would be fine. 

Three to five options. 
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Pilot responses: 


Two or three options. 

No more than three options. [3 participants] 

The pilot would probably choose the option that saves the most time while the company would 
want to choose the option that saves the most fuel, but most of the time those are probably the 
same route. 

The pilot would find it useful to have more than one option for the negotiation process. 

The main concern with these types of re-routes is being clear of weather, unless there is another 
big issue, like fuel becoming a factor. 


The following questions were geared toward the controller SME: 


Based on your experience vectoring aircraft around weather, do weather gaps persist long enough 
for persistent routes to be useful or are individual UPRRs required? 


Gaps in weather depend on the part of the country. Gaps are usually most prominent when storms 
are building. Gaps are temporary in thunderstorms. When cells are moving across the country, 
e.g., west to east, gaps usually last longer. 

If three aircraft can go around weather in an organized manner, it’s a big advantage, because 
otherwise vectoring is necessary. 

Sometimes gaps persist in weather. With the number of airplanes handled in the Center, a route 
around the weather is going to be good for 45 minutes to an hour, mainly because the route has to 
take aircraft far enough away from weather. The whole idea is to get as many aircraft around the 
weather as possible in a short period of time. Routes should be good for 30 minutes at a 
minimum, because there are so many airplanes to get through. It is a problem if routes are only 
good for three or four airplanes. 

It depends on the storm. Ninety-five percent of storms move west to east and depending on where 
the hole is... 

It depends on the system. 

Aircraft do not try to shoot through holes that often unless the hole is really large. 


What agent should be the first to review a request for a UPRR if sent by data link — air traffic 
controller, TMU, controller DST, other? 


The controller should be the first contact and will get the coordination going. 

If the UPRR request is sent by data link, the request should go to the TMC because they are going 
to know how that aircraft fits into the flow and they have information at their disposal, such as 
flow control restrictions. They will relay the information to the controller, which should only take 
a minute at most. But if the request is by voice, the controller would make the decision and deal 
with the ramifications afterwards. 

If it is not busy and the request affects one sector, the R-side controller could review the UPRR 
request or the D-side controller could review it. If the request affects more than one center, the 
TMU must be involved. 

The TMU should be the first to review a UPRR request. [2 participants] 


Should an air traffic controller have a role in strategic trajectory negotiation? If not, where should 
this negotiation be done? 


The controllers must be involved because they know where the airplanes are flying. 

When route changes are involved, the TMC and Command Center should definitely be the first 
negotiators, because they have the bigger picture. 

If the re-route affects multiple sectors, the TMU would handle the strategic negotiations, but it 
would be good to have the controller involved. 

Asa controller, I would like to be involved in trajectory negotiations that involve my sector and 
possibly upstream sectors because that traffic flow will come through my sector. 

Controllers should be involved in strategic trajectory negotiation. 
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When there are multiple but nearby routes, how would you re-route aircraft in the event of weather 
if some aircraft are RNP equipped and some are not? 


Better equipage typically translates to more effective re-routing and less vectoring. 

The main thing is being able to re-route all aircraft in the same direction around weather. When 
an aircraft does not follow the flow, it is difficult to fit them back in after the re-route. 

If all aircraft are going to the same airport, off-setting routes would be fine. If not, defining routes 
that overlay each other and are altitude separated is fine. 

From a workload standpoint, I would first re-route the aircraft that are easiest to issue clearances 
to, which would be the equipped aircraft. 

I would probably re-route aircraft the same way that was done in the scenario today, as close as 
possible to the weather and to the flow. If the aircraft were at different altitudes, I would put them 
right next to each other, as close to the weather as they would like to be. 


When would you notify aircraft that they need to re-route? 10 nautical miles prior to re-route? 


Aircraft should be notified of the re-route as soon as possible in order to avoid making a 
severe turn (more than 30 degrees). [2 participants] 

The controller should notify the aircraft of the re-route as soon as it is known to give the 
pilots time to prepare. [2 participants] 

If a re-route is required, I would notify the aircraft as soon as it came into my sector. 


The following questions were focused toward the pilot SME: 


Should a flight crew have the ability to accept/reject a request for 4DT information (ADS-C/EPP) 
from the air navigation service provider (ATC) or should these requests be automatically granted 
and executed by the FMS? Why? 


In today’s ATC environment, the flight crew should have the ability to accept or reject. 
The ADS-C request should be auto-loaded and auto-executed. [4 participants] 

The pilot should not have to deal with passive requests; it would increase workload. 

It is not any different that ADS-B transmitting your position, ADS-C just provides more 
information. 


Do you see the flight crew as having a role in strategic trajectory negotiation for UPRRs after the 
aircraft is airborne or should this trajectory negotiation occur between the airline operation center 
and the service provider and the solution uploaded to the flight deck? 


Negotiation should occur with the pilot if the change is near term (within the next range ring on 
the navigation display). Beyond that, it is reasonable for the AOC to be involved. 

For longer term re-routes, the negotiation should be done with the AOC. The pilot does not need 
to be part of the process as long as the solution was developed by those that have more 
information. The pilot will notify ATC if there are any issues with the re-route once loaded. 

The pilot should be involved in the strategic negotiation once airborne because they have 
information about the immediate weather that the AOC does not have. 

Ideally, the pilot would negotiate with the AOC who in turn negotiates with the TMU and ATC. 
The pilot should be involved in strategic trajectory negotiation. 
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7.2.4 General Comments 


The following is a list of comments received from the controller and pilot when conducting the 
demonstration scenarios and from ad hoc questions asked during the discussion session. 


Controller comments: 

e When implementing dynamic re-routes, the clearances sent via Data Comm should auto-update 
the flight plan information, but it’s important not to forget to do the same for the voice clearance 
re-routes. 

e = The first agent to review a UPRR sent from an aircraft is dependent on the scale of the re-route; 
multi-sector re-routes would likely go to the Center TMU first. 

e UPRRs should be presented to controllers only after having been scrutinized by a conflict probe. 

e Dynamic re-routes should have some identifier that indicates they were generated by TMU; this 
lets controllers know they have been vetted by traffic management or should be implemented as 
shown. 

e With an increased-number of aircraft on UPRRs, the automation tools will have to evolve to help 
the controller maintain a mental picture about where each aircraft is going. 

e = The ability to hear party-line information is important for pop-up events such as turbulence or 
icing; however, pilots generally know when there is weather and are expecting to get re-routed at 
some point so party-line information is not as important. 

e Traffic management could not be done by the R-side controller when busy but could possibly be 
done by the D-side controller, or it could be shared between the TMU and controller. The TMU 
would have the bigger picture for managing traffic between sectors. 


Pilot comments: 
e = The loss of party-line information only affects the pilots because the controller has situation 
awareness of the whole environment. 
e Normal ATC interaction would be to accept the clearance (tell ATC you are going to do it), then 
execute it; although two pilots indicated the order did not matter as long as there were no errors. 
e If time passes between when a route is loaded into the FMC and when it is executed, the airplane 
has traveled a distance which could cause the aircraft to make a sharp turn to stay on path. 


8 Conclusions 


An Advanced 4DT concept will integrate existing and proposed TBO technologies, as well as 
incorporate new technology where needed, to create automation tools and procedures that support 
gate-to-gate TBO. NASA developed an Advanced TBO Prototype simulation toolkit that 
demonstrated some of the functionality that could be part of an Advanced 4DT TBO concept. The 
objectives of the Prototype were to develop an initial TBO simulation capability leveraging existing 
tools where possible and rapid prototypes as needed; develop an initial set of requirements for ground 
and airborne systems for performing TBO operations; and engage stakeholders and SMEs in the 
development and refinement of the concept. Controller and pilot SMEs participated in discussions 
on an Advanced 4DT operational concept and were provided an interactive demonstration of the TBO 
Prototype using four example scenarios. The SMEs provided feedback on potential operational, 
technological, and procedural opportunities and concerns. 


After participating in the interactive scenarios, the controller and pilot SMEs provided input on the 
capabilities demonstrated. The controller SMEs felt that it was easy to understand what was 
happening during each scenario and that they would use the operational capabilities demonstrated 
(DRNP, DRNAV, UPRR, RTA, A-IM) to re-route aircraft. They also felt that the operational 
capabilities demonstrated would not hinder their duties and could be used to manage traffic while 
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maintaining situation awareness and low mental workload. The pilot SMEs felt that the operational 
capabilities demonstrated (DRNP, UPRR, and RTA) would be useful for performing TBO and would 
not hinder their duties. They also felt that they could perform the operations encountered and still 
maintain situation awareness, low mental workload, and low physical workload. 


In today’s air traffic system, the tactical management of aircraft around weather is done using 
controller-issued vectors or clearances that allow for deviation from the current flight plan within 
some predefined limits. With vectoring, the controller issues heading instructions as necessary to 
steer the aircraft through a weather region while maintaining safe separation from nearby traffic. This 
has the side-effect that the pilot does not know when the controller will turn the aircraft back to rejoin 
their original route. Conversely, when the aircraft is provided with a deviation clearance, the 
controller will not have any way to know the exact route the aircraft will follow through the weather 
and needs to maintain a significant region of airspace clear for the deviating aircraft. The SMEs felt 
the TBO concept demonstrated produced defined routings around the weather which resulted in a 
more organized, consistent flow of traffic where it was clear to both the controller and pilot what 
route the aircraft was to follow. This would give the controller more confidence in re-routing the 
traffic closer together because the exact route would be known. The controller SMEs indicated that 
better equipage typically translates to more effective re-routing and less vectoring. It is important to 
be able to re-route all aircraft in the same direction around weather; however, opposite direction 
traffic must be taken into consideration to avoid conflicts. When re-routing is required and re-routing 
plans are developed, the aircraft should be notified as soon as possible to allow time to prepare. 


One common theme throughout the activity was that, in general, the controller SMEs felt the TMU 
or TMC should be responsible for generating and negotiating the operational constraints 
demonstrated (dynamic re-routes, UPRR initial approval, time constraints, and spacing constraints) 
in cooperation with the Command Center, while ATC should be responsible for the implementation 
of those constraints. This function allocation is applicable particularly when the traffic load is heavy 
or the re-route involves more than one sector. Some controllers felt that the data controller could also 
be responsible for re-route planning but that the radar controller should only handle re-route planning 
if the traffic loads were normal, or for pop-up weather events. However, the controllers did feel that 
they should be consulted when the re-routes are developed, particularly when the re-route affects 
their sector, because they have more information on the conditions in the immediate area and better 
insight on the effects of the route changes. The SMEs noted that trajectory negotiation and changes 
could also be done by automation as long as humans set the negotiation parameters and have the 
ability to intervene when conditions change. 


The pilot SMEs indicated that there would be plenty of time to re-plan a route from the flight deck 
during en route operations. Dispatch would not have any issues with the pilot re-planning the route 
and would not impose constraints limiting the number of re-routes. Some pilots felt they were 
obligated to inform the dispatcher of the re-route and some stated that dispatch must be notified when 
the route caused deviations of 100 nautical miles or more. Many factors determine when it is 
beneficial to request a UPRR, such as passenger’s connecting flights, amount of fuel onboard, and 
time and fuel savings. Pilot SME opinion varied on the minimum amount of time and fuel savings 
required to justify the request for a UPRR; from one to five minutes time savings and 100 to 500 
pounds of fuel savings. When using automation onboard the aircraft to generate UPRR options, the 
pilot SMEs indicated that they would only want two or three options to select from. Having more 
than one option available aids in the negotiation process. The controller SMEs indicated they would 
trust using an airborne generated trajectory; however, they would verify the trajectory and monitor 
conformance. 


44 


Both the controller and pilot SMEs felt that Data Comm would be very beneficial for TBO operations. 
Data Comm would result in less workload due to reduced communications, would eliminate issues 
due to language barriers and frequency problems, and would make receiving, loading, accepting, and 
executing clearances easier, less ambiguous, and more expeditious. However, it was noted that pilots 
may not be able to anticipate situations, such as re-routes and turbulence, when they are unable to 
hear other aircraft communications. Procedures for loading and accepting data link messages must 
also be properly defined. 


Other automation and technology the controller SMEs felt would be needed to successfully conduct 
TBO operations included the ability to display where the re-route will reconnect to the active route, 
the ability to create a re-route for a stream of aircraft, a conflict probe applied to the UPRR prior to 
sending to the controller, an indication that a UPRR has been received by the ground automation, a 
method of displaying aircraft equipage level to show each aircraft’s TBO and data link capabilities, 
and the ability to view the active route for multiple aircraft. Although a few controller SMEs 
indicated it would be beneficial to view the current flight plan as well as the planned route along with 
turn geometry, most felt that viewing the 4DT of each aircraft, especially the vertical profile, is too 
much information for a controller. Suggestions were also given for the ground-based and flight deck 
user interface, such as an RTA status indication showing the time early or late in meeting that RTA. 
The pilot SMEs were also concerned with the current implementation for sending a UPRR request 
for approval which resulted in an open execute light. It is not good practice to leave an open execute 
for an extended period of time but the pilots did understand that the prototype implementation of this 
capability was not intended to mimic a proposed operational procedure but, rather, a proposed 
functionality that needs an operational procedure definition. 


The SMEs also noted other benefits of the TBO functionality demonstrated. These benefits include 
improved traffic flow, fuel and time savings, and decreased workload. The TBO functionality that 
would provide the most benefit with the least equipage was identified as RTAs, dynamic re-routes 
that are defined with latitudes and longitudes, the ability to receive UPRR requests via Data Comm, 
and the ability to view re-route options onboard the aircraft. 


The SMEs identified some challenges in implementing a TBO concept. These included education 
(i.e., training and change in mindset), consistent operations in a mixed equipage environment where 
all aircraft do not have the same capabilities/functionality, FAA implementation of new TBO 
equipment, and purchase of the necessary equipment by the airlines. 


Overall, the SMEs felt that the Advanced TBO concept presented and Prototype demonstrated had 


the potential for improving en route operations. The feedback obtained during this activity will be 
used in future research and development of Advanced TBO concepts. 
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Appendix A: Post Scenario Questionnaires 


At the end of each demonstration scenario, the participants completed a post scenario questionnaire. 
Pilots completed the questionnaire shown in Table A.1 and controllers completed the questionnaire 
shown in Table A.2. 


Table A.1. Pilot Post Scenario Questionnaire. 


Focus Group Activity - Pilot Strongly |Disagree| Slightly | Neither | Slightly | Agree | Strongly 
: . i Disagree | agree or | Agree Agree 
Post-Scenario Ratings i 
Please rate agreement with statements based on scenario just encountered 
A. This operational capability will be useful to me for 
performing trajectory-based operations. 


B. This operational capability would hinder my duties. Pot YET 


C. | could perform this operation (D-RNP, user-preferred 
route, RTA) and maintain my situation awareness. 


D. | could perform this operation while maintaining low mental 
workload. 


E. | could perform this operation while maintaining low 
physical workload. 


F. The user interface was effective for performing this 
operation (D-RNP, user-preferred route, RTA). 


Please rate agreement with statements based on scenario just encountered 


Focus Group Activity - Controller 1 : Slightly | Agree |Strongly 
A 
Post-Scenario Ratings i wie 
6 


B. It was easy to understand what was going on during this 
scenario (in terms of mental effort required). 


C. | would use this operational capability (D-RNP, D-RNAV, user- 
preferred route, RTA, A-IM) to reroute aircraft. 
D. This sce cides cs ieasetians peieec capability would hinder my duties. Pt 
E. | could use this iiss ancl nese capability to manage traffic and still 
maintain my situation awareness. 
F. | could use this operational capability to manage traffic and 
maintain low mental workload. 


G. Which controller position(s) should handle the operational capabilities encountered during this scenario? 


47 


Appendix B: Discussion Questions 


B.1 Operational Questions 


B.1.1 Controller and Pilot 


SS 


8. 


9: 


From your perspective, what are the benefits/impacts of trajectory-based operations (TBO)? 

Will TBO help you in performing your job? Why? 

Do you feel that TBO will increase, decrease, or otherwise change your workload? If so, in what way? 
What challenges do you see in implementing a TBO concept? Please comment on issues such as 
mixed equipage environment, etc. 

Do you prefer segregated airspace in which equipped and unequipped aircraft do not operate together 
or do you believe there is a role for integrated airspace in which equipped and unequipped aircraft do 
operate together? 

Do you have any safety concerns or issues with the TBO concept that was presented to you today? If 
so, what are they? 

How do you think these new TBO procedures should be integrated with current operational 
procedures? 

What do you think the humans’ role should be in trajectory negotiation and changes? (Note: Does 
management (TMC) setup negotiation strategy and DST prompts controller and pilot?) 

How do you anticipate the airlines will attempt to game the system? Do the airlines do this today? 


B.1.2 Controller 


10. 
11. 


12. 


13. 


How would you monitor pilot conformance to RTAs? To IM clearances? 

How much time would you have to evaluate or generate proposed dynamic routes? Under normal 
conditions? Under sever weather conditions? 

When would you want to be involved in developing dynamic rerouting? What would you want the role 
of the supervisor and traffic management unit to be? 

How would you review a proposed re-route before issuing it to aircraft? What information would you 
need? 


B.1.3 Pilot 


14. 
15. 
16. 
17. 


18. 


How much time would you have to devote to re-plan your route when you’re in cruise flight? 

Do you feel that your dispatchers would be supportive of you re-planning the route while en route? 
What constraints may your airline impose to limit the number of re-routes that are generated by the 
flight deck (i.e., need dispatch concurrence for re-routes that deviate more than 100 nautical miles from 
the original route)? 

Do you think that these constraints may be relaxed as route re-planning from the flight deck becomes 
more normal? 

When is it beneficial to do user preferred routing? How much time / fuel need to be saved? 


B.2 Technological Questions 


B.2.1 Controller and Pilot 


What additional automation/tool capabilities do you think you would need to successfully conduct 
operations that you saw during this demonstration? 

What subset of TBO functionality would produce the greatest benefit with minimal equipage 
requirements? 
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B.2.2 Controller 


we 


Soo 


Should an air traffic controller have the ability to visualize an aircraft’s planned 4D trajectory? If so, 
by what method — 3D path, separate vertical/horizontal profiles, other? If not, why? 

Would you trust using an airborne generated trajectory for scheduling and sequencing? 

What information will you need to enable you to plan and manage aircraft 4D trajectories? 

Do you have any specific ideas/suggestions for a user interface? 

What level of detail would you like to know about an aircraft’s level of equipage? 


B.2.3 Pilot 


Have you ever conducted an RTA operation? If so, have you used the time component of the 4D 
trajectory? 

What information will you need to enable you to conform to a 4D trajectory? 

Do you have any specific ideas/suggestions for modifications to the user interface? 


B.3 Procedural Questions 


B.3.1 Controller and Pilot 


1. 


Assuming multiple route options meet the constraints, how many options would you want to see 
displayed? Would you like the ability to sort based on user-preferred business models? 


B.3.2 Controller 


Based on your experience vectoring aircraft around weather, do weather gaps persist long enough for 
persistent routes to be useful or are individual user-preferred routes required? 

What agent should be the first to review a request for a user-preferred route if sent by data link — air 
traffic controller, traffic management unit, controller decision support tool, other? 

Should an air traffic controller have a role in strategic trajectory negotiation? If not, where should this 
negotiation be done? 

When there are multiple but nearby routes, how would you re-route aircraft in the event of weather if 
some aircraft are RNP equipped and some are not? 

When would you notify aircraft that they need to re-route? 10 nautical miles prior to re-route? 


B.3.3 Pilot 


Should a flight crew have the ability to accept/reject a request for 4D trajectory information (ADS-C / 
EPP) from the air navigation service provider (ATC) or should these requests be automatically granted 
and executed by the FMS? Why? 

Do you see the flight crew as having a role in strategic trajectory negotiation for user preferred 
routings after the aircraft is airborne or should this trajectory negotiation occur between the airline 
operation center and the service provider and the solution uploaded to the flight deck? 
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